ncmagel@ndsuvax.UUCP (ken magel) (07/15/86)
I appreciate the several replies I received to my earlier message
concerning the crc errors I frequently encounter when binhexing downloaded
files. Those replies left two questions still in doubt:
1. Where is the end of the material which should be retained for binhexing?
That is, some files end with two hyphens and a couple of blanks and a colon. How much, if any, of that should be retained? How does one tell where the CRC is? 2. If I have access to FEDIT, or some other file editor on the Macintosh, how
can I repair a file which gets a bad crc error? That is, is there some field which can be patched to reflect the crc value which binhex would compute?
Alternatively can binhex4 or binhex5 be patched to save the file in spite of a
crc error?
Thanks for your help.
By the way, as a somewhat unrelated question, I noticed that COMPUSERVE's
Macintosh downloads are rather out of date in many cases. For example,
COMPUSERVE has FEDIT3.00 even though 3.05 was distributed on this net many
months ago and versions of at least 3.8 are around. How does one get
access to more recent downloads? Thanks. allison@convexs.UUCP (07/17/86)
> I appreciate the several replies I received to my earlier message > concerning the crc errors I frequently encounter when binhexing downloaded > files. Those replies left two questions still in doubt: > > 1. Where is the end of the material which should be retained for binhexing? > That is, some files end with two hyphens and a couple of blanks and a colon. > How much, if any, of that should be retained? How does one tell where the > CRC is? The BinHex format uses a colon as "beginning-of-file" and "end-of-file", if you will. Also, the message "This file must be converted...." is required, I think. So, strip anything before the "This file..." message and everything after the "end-of-file" colon (but don't take out the colon!). Note that xbin (the unix-based binhex) is smart enough to ignore most, if not all, leading and trailing garbage that BinHex 4.0 barfs on. So, if you use the 'xbin -> "pack the .data, .info, and .rsrc files together" program (I use macbin) -> xmodem' scheme (or macget/macput for the MacTerminal die-hards, I guess), you don't usually have to worry about stripping off the leading and trailing garbage. Xmodem is your friend (usually). Brian Allison {allegra, ihnp4, uiucdcs, ctvax}!convex!allison Convex Computer Corp. Richardson, TX
werner@ut-ngp.UUCP (Werner Uhrig) (07/19/86)
> The BinHex format uses a colon as "beginning-of-file" and "end-of-file", if > you will. Also, the message "This file must be converted...." is required, > I think. So, strip anything before the "This file..." message and everything > after the "end-of-file" colon (but don't take out the colon!). > > Note that xbin (the unix-based binhex) is smart enough to ignore most, if not > all, leading and trailing garbage that BinHex 4.0 barfs on. the danger in using xbin and macput rather than downloading the complete article with xmodem, is that you may miss some plain-text information preceding (sometimes appended to, which I hate and miss nearly *ALWYAS*) the binhex-part. So it always pays to, at least, check the articles in *.sources* for such text. Personally, I usually post an announcement to net.micro.mac to indicate something I put in net.sources.mac and repeat that message at the beginning of the net.sources.mac article. I'm not aware of any standards here, other than common sense. ---Werner
benn@sphinx.UChicago.UUCP (T Cox) (07/22/86)
> By the way, as a somewhat unrelated question, I noticed that COMPUSERVE's >Macintosh downloads are rather out of date in many cases. For example, >COMPUSERVE has FEDIT3.00 even though 3.05 was distributed on this net many >months ago and versions of at least 3.8 are around. How does one get >access to more recent downloads? Thanks. As I've seen it, CServe tends to hang on to old uploads sort of endlessly. So if you see FEdit 3.00, that doesn't mean 3.05 isn't up there too. Sometimes it'll be in a different data library [dumb, but it happens] or just elsewhere in the same library. And if it's not there at all, then YOU should think about uploading it yourself when you find it. Somebody's gotta post it before the rest of us can grab it, you know! -= Thomas Cox =- CompuServe: 76317,3121 GEnie: CLIPJOINT UUCP: c/o ...ihnp4!gargoyle!sphinx!see1