[comp.sys.mac] Conjecture: why several tech notes failed

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