Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!uw-beaver!tektronix!orca!tekecs!doghouse!snoopy
From: snoopy@doghouse.gwd.tek.com (Snoopy)
Newsgroups: comp.unix.questions
Subject: Re: tar vs. cpio
Message-ID: <8684@tekecs.TEK.COM>
Date: Fri, 12-Jun-87 13:15:10 EDT
Article-I.D.: tekecs.8684
Posted: Fri Jun 12 13:15:10 1987
Date-Received: Sun, 21-Jun-87 01:48:05 EDT
References: <178@ttrdd.UUCP> <4750008@hpirs.HP.COM>
Sender: nobody@tekecs.TEK.COM
Reply-To: snoopy@doghouse.gwd.tek.com (Snoopy)
Organization: The Daisy Hill Puppy Farm
Lines: 25

In article <4750008@hpirs.HP.COM> jrg@hpirs.HP.COM (Jeff Glasson) writes:

>One advantage cpio has over tar is the ability to archive and re-create
>special files (i.e. device files, named pipes, etc.).  Tar only knows
>how to handle symbolic links.

I've taught cpio about symbolic links (*), has anyone taught tar
about special files?  About multiple volume media?  Tar's code is
orders of magnitude cleaner than cpio's.

(*) If anyone else tries this, I suggest leaving the default behaviour
the same as it is now, and handling symlinks as symlinks if the 'L'
option is given.  You will want to make use of lstat(2) and readlink(2).
Store the path that the link points to where the contents of a regular
file would be.  Don't add a trailing NULL.  Make the 'file length' the
length of the pathname.  For restoring archives, you will need to use
symlink(2).  Consider carefully which cases need to have the main loop
skip reading the 'file contents'.  Make sure your test cases include
"cpio -it" and pulling individual files out of archives.

Snoopy
tektronix!doghouse.gwd!snoopy
snoopy@doghouse.gwd.tek.com

"cpio : Input not in cpio format. (cpio5)"