Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!killer!csccat!loci From: loci@csccat.UUCP (Chuck Brunow) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: ZOO/ARC Discussion Message-ID: <583@csccat.UUCP> Date: 10 May 88 02:46:06 GMT References: <827@uvm-gen.UUCP> <21371@amdcad.AMD.COM> <542@csccat.UUCP> <164@falkor.UUCP> Reply-To: loci@csccat.UUCP (Chuck Brunow) Organization: if you say so Lines: 61 Keywords: on and on and on In article <164@falkor.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >Chuck Brunow (loci@csccat.UUCP) writes: >> In article <21371@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: >> > >> >My understanding is that zoo can handle directories and arc can't. If >> >that is true, it would seem zoo is preferable. >> >Looks like Chuck got up on the wrong side of the bed. Not only did he >miss the entire point that Phil was making (quite eloquently, I believe), I think you're missing my point: IT TAKES TOO LONG TO WADE THOUGH ARCHIVERS. Got it? I don't want to keep copies of 17 (and counting) archivers, and I want to see what in a file QUICKLY. The local machine which archives the good stuff only supports ARC. Not my choice, theirs. I choose none of the above because I'm not going to keep most of this stuff: I just want a fast synopsis. Is that reasonable? > >Now, to business! The point made about zoo being able to handle directories >is that you can save a sub-treee using zoo. In arc, there is no knowledge >of the directory structure the files came from. You can have only one >file named "MAKEFILE" in an .ARC file, but several (one per directory) in >a zoo archive. Consider how useful/useless tar and cpio would be if >they didn't know how to make use of the UNIX filesystem. I'd say that >zoo is to (UNIX's) tar/cpio as arc is to (UNIX's) ar. Yes, "the file >system's already got directories", but that is the argument *in favor* >of an archive method that understands them! Let me clarify one point: TAR is a TAPE ARCHIVER. That's where it got it's name. Nobody would seriously use it for anything else. CPIO is only slightly better. But these aren't viable comparisons because nobody is gonna argue that their not very useful. If you want to make a comparison, lets talk about "ar", the object librarian, is directly linkable to compiles, etc., etc. Now, to business! The point made about zoo being able to handle directories is that the last thing I want somebody posting is an entire directory tree. That adds even more layers to layers, to layers. Is this making sense to you? I DON'T WANT MORE LAYERS, I WANT LESS. Adding more space just invites more junk. I want a USER-FRIENDLY way to scan the contents of files quickly so I can skip it if it's not interesting. Furthermore, as the posting also ignores my previous posting, let me refresh your memory. These archivers are not all PD, but rather use the USENET facilities to solicite $$$$$ from people which I consider improper. I received a number of responses to my posting which basically said, "Hey, don't worry about it. Everybody does it". However, bending rules results in stiffer rules: something nobody really wants. Lets review: when I see 300+ posting in a group, given limited time to peruse, and reading at 1200 baud what counts to me is SPEED. I haven't got enough spare disk space to keep all of the archivers, I'm not gonna send them money. If there are so many creative, intelligent and committed people out there as is claimed, it should be pretty easy to do better. That's my challenge. >--