usenet@cps3xx.UUCP (Usenet file owner) (03/14/90)
I just though of a great solution to the archiving problem. Any archive must maintain the same info as any filesystem right? Soooo why not make the archive itself a filesystem so that the standard commands (and workbench) work with it. Instead of having to type "fooarchiver dsfbkha archivename.foo file1 file2" simply type "copy myfiles archive:neato all". Simple enuff? To get a list of the files, type "dir archive:neato opt a" Spring break is coming up and I plan to implement this. The first cut will be making a compress.device that acts like the trackdisk.device, then I will simply need to mount any existing filesystem on that. The compress.device will use a file as its storage mechanism instead of actual hardware. Next cut, make a custom filesystem that understands the compress.device and can make assumptions about its operation to improve efficiency over a standard filesystem. So, what do you all think? Joe Porkka porkka@frith.egr.msu.edu
davidw@telxon.UUCP (David Wright) (03/14/90)
I think that's great! Everyone seems to be overlooking the WORST aspect of self-extracting files. They make you waste your time DLing extraction code you probobly don't need If you dl 5 things, each with the extraction code, you have just wasted 5*x amount of disk storage, time, etc. I suspect most people will prefer to use the extraction program, rather than trust self-extraction, and for those people, the self-extraction code is a waste. For the others, they simply need to learn the basics of operating a computer. If they don't like having the archiver handy, it's better that (maybe) 5% of the people are inconvienced instead of 95% wasting their time... -- _____________________________ Telxon: Amiga - The ONLY choice |________ | x4350 for REAL computing | | | davidw // |________| |
jones@uv4.eglin.af.mil (Calvin Jones, III) (03/16/90)
Joe Porkka <porkka@frith.egr.msu.edu> writes: > Any archive must maintain the same info as any filesystem right? Soooo > why not make the archive itself a filesystem so that the standard > commands (and workbench) work with it. Instead of having to type > "fooarchiver dsfbkha archivename.foo file1 file2" simply type "copy > myfiles archive:neato all". Simple enuff? To get a list of the files, > type "dir archive:neato opt a" Elegant! I like it! > Spring break is coming up and I plan to implement this. The first cut > will be making a compress.device that acts like the trackdisk.device, > then I will simply need to mount any existing filesystem on that. The > compress.device will use a file as its storage mechanism instead of > actual hardware. I believe that Dillon wrote something called FMSDISK that allows you to define a filesystem that resides entirely "within a file". You might want to examine it. (But I forgot where I got it!) > Next cut, make a custom filesystem that understands the compress.device > and can make assumptions about its operation to improve efficiency over > a standard filesystem. It would be best if the resulting archive would end up being a file that was completely compatible with either .ZOO or .LZH files. Or perhaps even an option (from a MOUNTLIST entry?) to have the archive come out to be .LHW. > So, what do you all think? I think you'd probably have more fun spending spring break on the beach getting drunk and chasing sweet-young-things-in-skimpy-bikinis, but I hope you do pursue this idea. --- Cal // Cal Jones - Internet: <Jones@UV4.Eglin.AF.Mil> \X/ BBS: 904-243-6219 1200-9600HST 340Meg, all Amiga Single Tasking? *JUST SAY NO!!!*
mikes@lakesys.lakesys.com (Mike Shawaluk) (03/16/90)
In article <495@telxon.UUCP> davidw@telxon.UUCP (David Wright) writes: > I think that's great! Everyone seems to be overlooking the WORST >aspect of self-extracting files. > They make you waste your time DLing extraction code > you probobly don't need >If you dl 5 things, each with the extraction code, you have just wasted >5*x amount of disk storage, time, etc. I suspect most people will prefer to >use the extraction program, rather than trust self-extraction, and for those >people, the self-extraction code is a waste. For the others, they simply >need to learn the basics of operating a computer. If they don't like having >the archiver handy, it's better that (maybe) 5% of the people are inconvienced >instead of 95% wasting their time... I know that this is probably on the verge of flogging the proverbial dead horse, but from my understanding, the MAIN reason for having self-extracting files is to be able to extract the first program you get, when you don't have an extracter handy yet! For example, it's kinda tough to extract PKAZIP.ZIP, if you don't have PKAZIP yet, or even PKAZIP.ZOO or PKAZIP.LZH or ... whatever. If, however, the program PKAZIP.PAK were available, it could be downloaded, and would self-extract upon its name being typed (assuming, of course, that it wasn't padded or otherwise lengthened in size during the file transfer). Since the old PAK program always made files multiples of 1K long, this was usually not a problem (nowadays, where most people are using "smarter" file transfer protocols that preserve the file size, date, etc., this issue is fading away; I've never even used the "auto-chop" option on my current terminal program). Historically, the first usage (that I know of) for self-extracting files was with distributions of SEA's ARC program for the IBM PC. Since each version that was being introduced was using new compression methods, which were incompatible with the previous version of the program, one couldn't guarantee that an update would be able to be unpacked by the previous version, unless that file were compressed with the old version of the program, which, in many cases, made the file much larger than it would have been than if the newer version had been used. But by tacking on a self-extractor (which was based on the newer algorithms), the program could be unpacked, and the savings in space by using the newer compression methods more than offset the cost of tacking on the self-extraction code. In the case of PKZIP for the IBM PC, there is virtually NO wasted space, since the self-extraction code that's present can be plucked off the front of the original file via a small (896 byte) program, and the resultant code can be used by the user to distribute their own self-extracting files, if desired. I agree with the consensus that there is no need (or desire) for the majority of file collections to be self-extracting; this takes up extra space on both the sysop's computer and on my hard disk. However, for "starter kits" and distributions of packages via other means, including self-installing programs, this capability can be very useful. - Mike -- - Mike Shawaluk "Rarely have we seen a mailer -> DOMAIN: mikes@lakesys.lakesys.com fail which has thoroughly -> UUCP: ...!uunet!marque!lakesys!mikes followed these paths." -> BITNET: 7117SHAWALUK@MUCSD