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.
>--