pes@bath63.UUCP (06/19/87)
Bug in something -- either ARC or UUENCODE. My suspicion is that there is a
flaw in the 'Dumas' UUENCODE.TTP. I'm posting this in hopes that someone
else will have already spotted and analysed the problem, so that I won't
have to do it. (Basically, I'm lazy :-). The past two nights I've been
working thru the collection of UUENCODEd ARC files which I'd pulled from the
net but not done anything with yet. I noticed the same problem with several
of them. Specifically, I'd UUDECODE FRED.UUE to make FRED.ARC. While both:
ARC x FRED
ARC t FRED
appear to work fine (and in all cases the result appears to run properly)
ARC v FRED
gives a 2-bomb bombout.
I've poked around a little bit. In particular, I tried (with several of the
ARCs) putting the pieces back together into a new ARC and then comparing the
result with the originally received ARC file. In all cases the significant
difference was that the new ARC was shorter than the old one. They were
identical as far as length(new_arc) -- bar a tiny bit of the header which
appears to be a date field -- but the original archive in all cases had a
bunch of extra trash (generally repetitions of a single byte) at the end.
In those cases where the trash *was* repeating, it was obviously present in
the UUENCODED file, so it's not UUDECODE tacking it on.
ARC of course will try to process this as being the header for a 'next
file'. And it would appear that either ARC 'v' uses some header field that
'x' and 't' do not; or that 'x' and 't' are more clever about validating
header fields before they try to use them.
My suspicion is that the spurious stuff is being added by UUENCODE -- and
if this is true, I'd suspect it's the Dumas UUENCODE, either the original
Dumas object, or UUENCODE produced from the Dumas source by a particular
compiler. My reasoning is as follows. People who have ARC are quite likely
to be using it for personal use as well. They will thus process ARCs which
they have created and so would notice the fault if they tried 'v'ing one of
their own ARCs; quite likely some of the other ARC operations would have
problems as well. On the other hand, people UUENCODEing things generally
don't look at them again themselves -- rather they post them off to
somewhere. The recipient, if he has problems, will probably blame them on
some fault during transmission through the net. A UUENCODE fault would also
be less likely to be spotted because in most cases it doesn't matter if the
file grows some extra stuff on the end -- particularly if it is innocuous
stuff like new-lines.
On the chance that they might read usenet news, the two names which
instantly come to mind are Stephan Leicht in Germany and Rodney Peck in the
States. Things I've received from both of them recently have had this
problem. In both cases, the intended contents of the postings have arrived
properly, and the only apparent problem is with the 'long listing' ('v') of
the received .ARC file.
In summary, my guess is that some UUENCODE version is not stopping at the
end of the input file, but is rather carrying on, probably, to the end of
the block or buffer during which the end occurred. There's a very outside
chance that it might instead be ARC doing this, but I doubt it. Has anyone
else seen this and puzzled it out? Or am I to be the lucky one who gets to
analyse it?