Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!uxc!iuvax!mailrus!tut.cis.ohio-state.edu!ucbvax!pro-carolina.UUCP!delton
From: delton@pro-carolina.UUCP (Don Elton)
Newsgroups: comp.sys.apple
Subject: Re: Shrinkit/Binary II stuff
Message-ID: <8905230506.AA05638@obsolete.UUCP>
Date: 23 May 89 03:54:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 24

Network Comment: to #2927 by obsolete!agate!e260-3f.berkeley.edu!labc-3dc%ucbvax.berkeley.edu

The point of having files on non-apple systems encased in a BNY structure (or
something like it) is that it makes the file on your disk after you download
it the same as the file that was originally uploaded.  This means same data,
same data length, same file type, same dates, same aux type, access etc etc
etc.  Everything that gets uploaded won't be a SHK file or a BQY file but
everything uploaded could well be put in BNY on upload and removed from it on
download, including an SHK file.  Using this scheme when you download an SHK
file etc it would always have the right file type for identification purposes.
Sure I could identify an SHK file and assign a unique file type to it but
using this scheme I'd have to change my program every time the next dozen
packers come down the pike to accomodate each one of them with unique
identification and file type info.  By using the BNY packaging this never has
to be done again no matter how many packers/archivers come out down the road.

(The method I'm suggesting has worked pretty well on the Mac incidentally).

UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com

Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
     US Mail: 3207 Berkeley Forest Drive, Columbia, SC  29209-4111