delton@pro-carolina.UUCP (Don Elton) (05/19/89)
Network Comment: to #2734 by obsolete!nicholaA%moravian.edu%relay.cs.net
Binary II was indeed originally designed to accomodate compression of
individual members as the original format calls for a byte to flag the type of
compression in use by individual members. The only systems that can really
handle .SIT (stuffit) files without MacBinary headers are Mac systems since
you can't expect Compuserve, the Source etc to write in special code to
accomodate Macs. If you download a straight SIT file it won't have the proper
file type on the Mac disk unless MacBinary is used to pacakage the SIT file
when it was originally uploaded. Perhaps comm programs should automatically
package SHK files as Binary II if they aren't already in Binary II format at
the time of an upload. Upon download they would be extracted out of the
Binary II file and ready for decompression with Shrinkit. For folks with
programs that don't do auto-binary II on uploads, Shrinkit should ideally let
the user put the file into that format.
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-4111blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (05/20/89)
In article <8905190506.AA19084@obsolete.UUCP> delton@pro-carolina.UUCP (Don Elton) writes: >Network Comment: to #2734 by obsolete!nicholaA%moravian.edu%relay.cs.net > [...] The only systems that can really >handle .SIT (stuffit) files without MacBinary headers are Mac systems since >you can't expect Compuserve, the Source etc to write in special code to >accomodate Macs. If you download a straight SIT file it won't have the proper >file type on the Mac disk unless MacBinary is used to pacakage the SIT file >when it was originally uploaded. This is (as far as I'm aware) correct - but ShrinkIt doesn't need the filetype/auxtype to be able to recognize it's files, and it doesn't need them in order to properly retain the filetype/auxtype of the files that it holds within an archive. So, a host doesn't have to handle the file any differently than a text file, which seems like a reasonable limitation :) The one exception that I could see to this would be listing the contents of an archive, which is trivial, as well as non-essential (given a reasonable description of the archive). >Perhaps comm programs should automatically >package SHK files as Binary II if they aren't already in Binary II format at >the time of an upload. Upon download they would be extracted out of the >Binary II file and ready for decompression with Shrinkit. For folks with >programs that don't do auto-binary II on uploads, Shrinkit should ideally let >the user put the file into that format. What purpose would this serve? Given that ShrinkIt (and anything else that deals with NuFX archives like it's supposed to) does not require what the Binary ][ header would preserve... This seems like redundancy to me, as the files would already be "ready for decompression with ShrinkIt". >UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton >ARPA: crash!pro-carolina!delton@nosc.mil >INET: delton@pro-carolina.cts.com ------------------------------------------------------------------------------ Jason Blochowiak (blochowi@garfield.cs.wisc.edu) "Not your average iconoclast..." ------------------------------------------------------------------------------
labc-3dc@e260-3f.berkeley.edu (Andy McFadden) (05/20/89)
In article <8905190506.AA19084@obsolete.UUCP> delton@pro-carolina.UUCP (Don Elton) writes: [ stuff thwacked ] > Perhaps comm programs should automatically >package SHK files as Binary II if they aren't already in Binary II format at >the time of an upload. Upon download they would be extracted out of the >Binary II file and ready for decompression with Shrinkit. For folks with >programs that don't do auto-binary II on uploads, Shrinkit should ideally let >the user put the file into that format. Why? What's the point? ShrinkIt can unpack BLU and ACU archives. Why not just do the following: 1) Instruct the user to TURN OFF Binary II auto-extraction. 2) Instruct the user to unpack the file with ShrinkIt. THAT'S ALL YOU NEED TO DO!!! If you are *really* concerned about confusing the usr, have the comm program check the first six bytes of the file for the "NuFile" header. If it finds that, have it store the file as type $e0/8002. (or is it e0/0002?) >INET: delton@pro-carolina.cts.com
delton@pro-carolina.UUCP (Don Elton) (05/23/89)
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-4111nicholaA@moravian.EDU (05/23/89)
> >In article <8905190506.AA19084@obsolete.UUCP> delton@pro-carolina.UUCP >(Don El ton) writes: >[ stuff thwacked ] >>Perhaps comm programs should automatically >>package SHK files as Binary II if they aren't already in Binary II format at >>the time of an upload. Upon download they would be extracted out of the >>Binary II file and ready for decompression with Shrinkit. For folks with >>programs that don't do auto-binary II on uploads, Shrinkit should ideally let >>the user put the file into that format. >Why? What's the point? The point is that if a NuFX archive created by ShrinkIt is uploaded to CIS or GEnie or The Source, it will lose its own attributes. Upon downloading, the user can not easily tell what type of file they have just received. It would be more convienient for the user if every upload would have a Binary II header attached, and every downloading terminal program would strip that header away, leaving the file's attributes intact. >ShrinkIt can unpack BLU and ACU archives. Why not just do the following: >1) Instruct the user to TURN OFF Binary II auto-extraction. >2) Instruct the user to unpack the file with ShrinkIt. >If you are *really* concerned about confusing the usr, have the comm >program check the first six bytes of the file for the "NuFile" header. If >it finds that, have it store the file as type $e0/8002. (or is it e0/0002?) Yes and No. I hold the opinion that comm programs should optionally add the Binary II header when uploading and strip it off when downloading. however, because i am the slightly biased author of NuFX, I also hold the opinion that to make the user's life easier that comm programs should check for the header of a NuFX file for the "NuFile" signature and then change the filetype/auxtype to $e0/$8002 if a Binary II header has not preceded the first xmodem block of an archive. The next version of ShrinkIt will automatically skip a Binary II header attached to a single NuFX archive and simplify the step for the user from 2 steps to 1. I am extremely opposed to any move to have ShrinkIt automatically add a Binary II header to the files IT creates. In my opinion, that should be the job of the terminal program transmitting these files, just as it is done in the Macintosh community. In this I wholeheartedly agree with Don Elton. >>INET: delton@pro-carolina.cts.com andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
nicholaA@moravian.EDU (05/23/89)
>>Perhaps comm programs should automatically >>package SHK files as Binary II if they aren't already in Binary II format at >>the time of an upload. Upon download they would be extracted out of the >>Binary II file and ready for decompression with Shrinkit. For folks with >>programs that don't do auto-binary II on uploads, Shrinkit should ideally let >>the user put the file into that format. >What purpose would this serve? Given that ShrinkIt (and anything else >that deals with NuFX archives like it's supposed to) does not require what >the Binary ][ header would preserve... This seems like redundancy to me, as >the files would already be "ready for decompression with ShrinkIt". The purpose it would serve would be to insure that the NuFX archive itself would maintain its attributes. If the IIgs Finder is modified to launch ShrinkIt when a user double-clicks on a ShrinkIt archive, then this feature for the user will stop working. Ideally you would have to have all terminal programs identify a NuFX file and restore their attributes based on that, but otherwise, having the TERMINAL PROGRAMS worry about Binary II is the most effective alternate solution. >>UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton >Jason Blochowiak (blochowi@garfield.cs.wisc.edu) andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
SEWALL@UCONNVM.BITNET (Murph Sewall) (05/24/89)
>The purpose it would serve would be to insure that the NuFX archive itself >would maintain its attributes. If the IIgs Finder is modified to launch >ShrinkIt when a user double-clicks on a ShrinkIt archive, then this >feature for the user will stop working. > >Ideally you would have to have all terminal programs identify a NuFX file and >restore their attributes based on that, but otherwise, having the TERMINAL >PROGRAMS worry about Binary II is the most effective alternate solution. I don't think one size is EVER going to fit all. These days, I download almost exclusively from this net, which means everything is BinSCII'd or Executioner'ed so when I EXEC, I get whatever ProDOS filetype the encrypted file had. However, if I download with XModem from a local IBM (or even C-64) bbs (as I have been known to do, at least once-upon-a-time) the file WILL be stored as a TXT (even though all 8-bits are preserved). If I happen to have "smart" XModem commware (I don't) that notices while the file is being received that it's a BNY, BQY, or NuFX and creates the appropriate file attributes, that's cool. HOWEVER, what's simple, easy, and MUCH LESS CONFUSING is being able to just execute BLU or ShrinkIT and have it ignore the fact that the downloaded file happens to be a TXT (I gather from Andy's comments that such is the case with ShrinkIT, and I know BLU ignores the filetype and the fact that TXT files have a 'start' address of $0000). Why not just have the next version of ShinkIT (and BLU for that matter) check the filetype and if it's TXT (or something else that's not correct) offer the user the option of changing (correcting) it? If ShinkIT (and BLU) are going to be general purpose Apple 2 utilities, isn't worrying about 'automagically' launching ShrinkIT when a recently downloaded archive is double-clicked a trifle exotic? Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
delton@pro-carolina.UUCP (Don Elton) (05/25/89)
Network Comment: to #2969 by obsolete!nicholaA%moravian.edu%relay.cs.net
While not making it automatic (to have ShrinkIt add a bny header) it would be
handy to have it as an option as many comm programs can't add it themselves.
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-4111nicholaA@moravian.EDU (05/25/89)
>Why not just have the next version of ShinkIT (and BLU for that matter) check >the filetype and if it's TXT (or something else that's not correct) offer the >user the option of changing (correcting) it? If ShinkIT (and BLU) are going >to be general purpose Apple 2 utilities, isn't worrying about 'automagically' >launching ShrinkIT when a recently downloaded archive is double-clicked a >trifle exotic? But if the attributes are not kept intact, whole civilizations will vanish beneath tidal waves, plagues will visit us once again, and entire cities will be swallowed by the earth. We can avoid this calamity by preparing to standardize Now! andy ---- Andy Nicholas CsNET: shrinkit@moravian.edu Box 435 InterNET: shrinkit%moravian.edu@relay.cs.net Moravian College uucp: rutgers!lafcol!lehi3b15!mc70!shrinkit Bethlehem, PA 18018 GEnie: shrinkit ---- AppleLink PE: shrinkit
SEWALL@UCONNVM.BITNET (Murph Sewall) (05/25/89)
>>Why not just have the next version of ShinkIT (and BLU for that matter) check >>the filetype and if it's TXT (or something else that's not correct) offer the >>user the option of changing (correcting) it? If ShinkIT (and BLU) are going >>to be general purpose Apple 2 utilities, isn't worrying about 'automagically' >>launching ShrinkIT when a recently downloaded archive is double-clicked a >>trifle exotic? > >But if the attributes are not kept intact, whole civilizations will vanish >beneath tidal waves, plagues will visit us once again, and entire >cities will be swallowed by the earth. We can avoid this calamity by >preparing to standardize Now! One purpose of an archive is to prserve the attributes of the files IN the archive. So, in order to preserve the attributes of the archive file itself, the proposal is to archive the archive. But what happens when the archived archive is downloaded from a (for instance) Fido-BBS? Looks like the solution is to archive the archived archive... :-O Murph Sewall Vaporware? ---> [Gary Larson returns 1/1/90] Prof. of Marketing Sewall@UConnVM.BITNET Business School sewall%uconnvm.bitnet@mitvma.mit.edu [INTERNET] U of Connecticut {psuvax1 or mcvax }!UCONNVM.BITNET!SEWALL [UUCP] (203) 486-5246 [FAX] (203) 486-2489 [PHONE] 41 49N 72 15W [ICBM] -+- I don't speak for my employer, though I frequently wish that I could (subject to change without notice; void where prohibited)
ART100@PSUVM.BITNET (Andy Tefft) (05/28/89)
In article <8905242324.AA24622@batman.moravian.edu>, nicholaA@moravian.EDU says: >But if the attributes are not kept intact, whole civilizations will vanish >beneath tidal waves, plagues will visit us once again, and entire >cities will be swallowed by the earth. We can avoid this calamity by >preparing to standardize Now! But why the heck do you need the attributes of the archive to be maintained? I can see if you're using the program to keep archives for yourself. But in that case you won't be uploading or downloading it, will you? I thought one of the purposes of the archive in the first place was to maintain the attributes of the files inside. Once I get the files out of an archive I get off the net, I delete the archive. Who cares what filetype it was, what its date was, as long as I can unpack it once! And if I cared about the date, it would be the date I downloaded it (so I could see how long it's been sitting there waiting for me to do something about it) rather than its original creation date. Face it, somewhere along the line, when you move a file to a non-apple, it's going to lose its apple attributes. You can't go on enveloping things indefinitely. Bundle it up once in an archive whose attributes aren't important, and be done with it! (exactly what shrinkit and BLU do now) The important attributes, those of the files inside, will still be preserved. Andy