brian@ut-sally.UUCP (12/07/87)
Just to make sure we're talking about the same thing, three of the November '87 tech notes failed because of CRC errors: 169, 170, 175. Another, 178, failed because somebody swallowed the last several lines of it. Like most everybody else, I'm entertaining anybody to send it to me or repost. Do I need to point out the importance of checking your postings _before_ you post them? Perhaps this was done; after all we do have a moderator. It looks to me like the three tech notes that failed with CRC all had the longest filenames. Perhaps binhex 4 never thought it would encounter a filename longer than 28 bytes (or so; I haven't actually done any tests.) Can anybody corroborate? Brian
jnp@daimi.UUCP (J|rgen N|rgaard) (12/10/87)
Earlier this year there has been trouble with tech-notes, that would not binhex correctly (the Mac program). Then the problem could be solved with a similiar program on unix-machines. The problem seemed to show up when the file-names where extremely long (28 might be the number). It seemed not to be so sensitive about file-names. Unfortunately I have lost the sources. -- Regards J|rgen N|rgaard e-mail: jnp@daimi.dk -------------------------------------------------------------------------------
shane@pepe.cc.umich.edu (Shane Looker) (12/11/87)
In article <9827@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes:
:
: It looks to me like the three tech notes that failed with CRC all had the
:longest filenames. Perhaps binhex 4 never thought it would encounter a
:filename longer than 28 bytes (or so; I haven't actually done any tests.) Can
:anybody corroborate?
:
:Brian
BinHex 4.0 always chokes if the file name is too long. I'm not sure what the
exact limit is, but it does happen.
Shane Looker | "He's dead Jim,
shane@pepe.cc.umich.edu | you grab his tricorder,
uunet!umix!pepe.cc.umich.edu!shane | I'll get his wallet."
Looker@um.cc.umich.edu
bytebug@felix.UUCP (Roger L. Long) (12/12/87)
In article <9827@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes: >Do I need to point out the importance of checking your postings _before_ you >post them? Perhaps this was done; after all we do have a moderator. All the postings of Tech Notes went out intact. Were they were munged is anyone's guess. > It looks to me like the three tech notes that failed with CRC all had the >longest filenames. Perhaps binhex 4 never thought it would encounter a >filename longer than 28 bytes (or so; I haven't actually done any tests.) Can >anybody corroborate? Well, BinHex 4 is the one who produced the Hqx files, so I would assume that it should be able to deHqx them. Most likely, the problem is that one or more sites down the line decided to drop characters and corrupted the posting. *sigh* -- Roger L. Long FileNet Corp {hplabs,trwrb}!felix!bytebug
denbeste@bgsuvax.UUCP (William C. DenBesten) (12/16/87)
in article <15811@felix.UUCP>, bytebug@felix.UUCP (Roger L. Long) says: > Well, BinHex 4 is the one who produced the Hqx files, so I would assume that > it should be able to deHqx them. Most likely, the problem is that one or more > sites down the line decided to drop characters and corrupted the posting. I have had troubles with binhex deHqxing technotes that I had encoded just moments before. I believe that binhex4 has a lurking bug that shows up in decoding technotes. I have since switched to using xbin. -bill