Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!hoptoad!gnu From: gnu@hoptoad.uucp (John Gilmore) Newsgroups: comp.sys.ibm.pc Subject: Re: ARC/ZOO/TAR Message-ID: <3456@hoptoad.uucp> Date: Thu, 3-Dec-87 07:59:11 EST Article-I.D.: hoptoad.3456 Posted: Thu Dec 3 07:59:11 1987 Date-Received: Mon, 7-Dec-87 01:22:28 EST References: <3027@umn-cs.cs.umn.edu> <617@omen.UUCP> Organization: Nebula Consultants in San Francisco Lines: 69 I don't normally read comp.sys.ibm.pc, but a friend pointed me at the discussion of PD tar here. Mostly tar was designed to run on larger systems, and to be compatible with the Unix tar program. When the Unix Standards effort (POSIX) looked reasonable enough to pick tar as a standard tape format, it was also intended as an easy way to read/write that format. Now it looks like the marching morons on the committee will end up picking cpio because it's System V specific, so tar is just for the folks who want a good tar program. It was ported to MSDOS by Mike Rendell (uunet!garfield!michael) and I rolled his changes back into the mainline sources for the release. Chuck Forsberg said that tar had a "shortcoming" that "compression wasn't built in". I see how people on MSDOS are forced to build tools that do everything by hand (e.g. compression, searching for files, etc) but I do not build things that way. Since my tar is truly public domain, you can take it and hack in the guts of compress somehow, but I will not take the changes back. Tar and compress are perfectly good tools, like a hammer and a chisel. I don't want to build a "hasel", I like them separate. If your OS and/or shell can't manage to connect two perfectly good tools, I guess you had better go build yourself a hasel. This problem is rampant on MSDOS and I wish you all luck in getting past it without throwing all your software away. Somehow I don't think OS/2 will be it, given Microsoft's past taste in software and current partnership with the biggest hardware company and the worst software company. But it's hard for me to run down an undocumented, unreleased system (except for its being announced with no doc and no release). Someone said tar doesn't write directory ownership, permission, etc. He's using an ancient tar program. Mine does, as does Berkeley's and the one spec'd by POSIX. It *does* archive empty directories, too. It can read tar archives with or without directories (old or new). Chuck also complained that there is no apparent standard for tar. When I started writing it, I followed up every case I heard of (on the net and off it) of people not being able to read tar tapes from some other system. The two problems I found were: Some systems write tape blocks larger than other systems' tape drives can read; and: some minor systems write their tapes out byte swapped because the idiot who programmed the driver didn't notice and then was too lily-livered to admit it was a bug. In short, there are no compatability problems with tar. People with old tar's can read the output of mine, and the worst they get is a few error messages. One thing Chuck mentioned that I *would* like to support is multiple volumes (floppies or tapes) but I want to do it such that: * You can read back any subset of the volumes, as long as they contain the data you want. You don't have to start from #1 and go to #N. * You don't have to tell tar "how big" a volume is. This doesn't work on any kind of tapes -- how much fits depends on how many errors occur, how often the tape stops, etc. * The design is reasonable enough that Unix tar's will pick it up. I've heard that DEC has done a multi-volume tar in their newest Ultrix release, but so far have seen no description of exactly what they did. I would be tickled if my Unix tar program became an MSDOS standard but it's not what I expect or hope for. I wrote it for the GNU project, the free Unix clone in source for everybody project. If you can use it, fine, if not, also fine. -- {pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com "Watch me change my world..." -- Liquid Theatre