joe@astph.UUCP (Joe Broniszewski) (11/07/90)
Are there any advantages of using tar over cpio for doing backups? We have both available and I am trying to figure out which is the best to use. Thanks for all info. -- Joe Broniszewski || Philadelphia Phillies || (814) 234-8592x34 astph!joe@psuvax1.psu.edu || Systems Department || psuvax1!astph!joe
tim@comcon.UUCP (Tim Brown) (11/11/90)
In article <57@astph.UUCP>, joe@astph.UUCP (Joe Broniszewski) writes: > Are there any advantages of using tar over cpio for doing backups? We > have both available and I am trying to figure out which is the best to > use. Thanks for all info. > -- Tar seems more portable. I did some archives on a system running ISC2.2 and could not read them on an Risc 6000/AIX machine. I suspect that if I had remembered to use the -c option it would have worked but tar works fine as is. -- Tim Brown | Computer Connection | uunet!seaeast.wa.com!comcon!tim |
prc@erbe.se (Robert Claeson) (11/12/90)
In a recent article tim@comcon.UUCP (Tim Brown) writes, on tar vs. cpio: >Tar seems more portable. I did some archives on a system running >ISC2.2 and could not read them on an Risc 6000/AIX machine. I suspect >that if I had remembered to use the -c option it would have worked >but tar works fine as is. The man page for cpio says that the -c option always should be used for creating archives that should be transferred to other machines. I believe that POSIX's cpio defaults to the -c option. I've run into cases where a machine refused to read my tar files. Using cpio instead worked just fine. Also, for backup purposes, cpio is probably the best. It comes *standard* with the ability to detect end-of-tape and create multi-volume archives. It has better support for incremental backups and selective restores. And it supports longer paths than tar's limit of 100 characters. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
bob@wyse.wyse.com (Bob McGowen x4312 dept208) (11/13/90)
In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: >In a recent article tim@comcon.UUCP (Tim Brown) writes, on tar vs. cpio: > >>Tar seems more portable. I did some archives on a system running ...11 deleted lines... >detect end-of-tape and create multi-volume archives. It has better >support for incremental backups and selective restores. And it supports >longer paths than tar's limit of 100 characters. > cpio will also backup device files where tar will not. This means named pipes such as SysV UNIX's use for lpsched and cron interprocess communication. I do not know if this is a problem for the operation of these two programs, however. Bob McGowan (standard disclaimer, these are my own ...) Product Support, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com
klarich@d.cs.okstate.edu (KLARICH TERRY JAME) (11/15/90)
In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: >In a recent article tim@comcon.UUCP (Tim Brown) writes, on tar vs. cpio: > >>Tar seems more portable. I did some archives on a system running >>ISC2.2 and could not read them on an Risc 6000/AIX machine. I suspect >>that if I had remembered to use the -c option it would have worked >>but tar works fine as is. > >The man page for cpio says that the -c option always should be used >for creating archives that should be transferred to other machines. >I believe that POSIX's cpio defaults to the -c option. > >I've run into cases where a machine refused to read my tar files. >Using cpio instead worked just fine. Also, for backup purposes, >cpio is probably the best. It comes *standard* with the ability to >detect end-of-tape and create multi-volume archives. It has better >support for incremental backups and selective restores. And it supports >longer paths than tar's limit of 100 characters. I know that cpio will also archive the special and device fines usualy found in in /dev. How ever, I think I remember that cpio won't handle symbolic links properly. I really don't remember if this was for everyone's cpio or just one vender's. -- -------------------------------------------------------------------------------- Terry Klarich <klarich@d.cs.okstate.edu> n5hts
sparks@power.viewlogic.com (Alan Sparks) (11/15/90)
In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: >Using cpio instead worked just fine. Also, for backup purposes, >cpio is probably the best. It comes *standard* with the ability to >detect end-of-tape and create multi-volume archives. It has better >support for incremental backups and selective restores. And it supports >longer paths than tar's limit of 100 characters. Which version of cpio are you running? The cpio man page on the Sun here says, "cpio does not support multiple volume tapes." (unquote). -Alan -- Alan Sparks voice: (508) 480-0881 Internet: sparks@viewlogic.com VIEWlogic Systems Inc., 293 Boston Post Rd. W., Marlboro MA 01752 Disclaimer: VIEWlogic didn't say this; I might have. Who wants to know?
mpreen@hemel.bull.co.uk (Malcolm Preen) (11/16/90)
sparks@power.viewlogic.com (Alan Sparks) writes: >In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: >>Using cpio instead worked just fine. Also, for backup purposes, >>cpio is probably the best. It comes *standard* with the ability to >>detect end-of-tape and create multi-volume archives. It has better >>support for incremental backups and selective restores. And it supports >>longer paths than tar's limit of 100 characters. >Which version of cpio are you running? The cpio man page on the >Sun here says, "cpio does not support multiple volume tapes." >(unquote). On our system, Bull DPX/2-300 running a mix of system V and BSD the man page for cpio says : ......... -I file Read the contents of file as input. If file is a character special device, when the first medium is full replace the medium and type a carriage return to continue to the next medium. Use only with the -i option. -O file Direct the output of cpio to file. If file is a character special device, when the first medium is full replace the medium and type a carriage return to continue to the next medium. Use only with the -o option. If cpio reaches end of medium (end of a diskette for example), when writing to (-o) or reading from (-i) a character special device, and -O and -I aren't used, cpio will print the message: If you want to go on, type device/file name when ready. To continue, you must replace the medium and type the character special device name (/dev/flop for example) and carriage return. You may want to continue by directing cpio to use a different device. For example, if you have two floppy drives you may want to switch between them so cpio can proceed while you are changing the floppies. (A carriage return alone causes the cpio process to exit.) -- |Malcolm Preen |Malcolm.Preen@hemel.bull.co.uk| |Bull HN Info. Sys. Ltd.|HM14 UK03 | |Maxted Road |Tel: +44 442 232222 x4367 | |Hemel Hempstead, UK |Fax: +44 442 234084 | +-----------------------+------------------------------+ -- |Malcolm Preen |Malcolm.Preen@hemel.bull.co.uk| |Bull HN Info. Sys. Ltd.|HM14 UK03 | |Maxted Road |Tel: +44 442 232222 x4367 | |Hemel Hempstead, UK |Fax: +44 442 234084 | +-----------------------+------------------------------+
prc@erbe.se (Robert Claeson) (11/17/90)
In a recent article klarich@d.cs.okstate.edu (KLARICH TERRY JAME) writes: >I know that cpio will also archive the special and device fines usualy >found in in /dev. How ever, I think I remember that cpio won't handle >symbolic links properly. I really don't remember if this was for >everyone's cpio or just one vender's. Those vendors whose systems has symbolic links (ie, most of them) have generally extended their cpio's to handle symbolic links. And, surprise, they have commonly done it in compatible ways. I routinely move cpio files with symbolic links among Sun's, Encore Multimax'es, DG AViiON's etc. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
prc@erbe.se (Robert Claeson) (11/17/90)
I wrote: >Using cpio instead worked just fine. Also, for backup purposes, >cpio is probably the best. It comes *standard* with the ability to >detect end-of-tape and create multi-volume archives. It has better >support for incremental backups and selective restores. And it supports >longer paths than tar's limit of 100 characters. And in a recent article, sparks@power.viewlogic.com (Alan Sparks) replied with: >Which version of cpio are you running? The cpio man page on the >Sun here says, "cpio does not support multiple volume tapes." >(unquote). I just checked on a SunOS 4.1 system and you're right, SunOS's cpio doesn't support multi-file cpio archives, and it lacks many of cpio's flags, such as -m, -C, -I, -O and the like. The cpio I'm generally using is the one found in, among others, UNIX System V Release 3.1 and later. It appears that Sun's cpio comes from some older version of System V, presumably Release 2. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se Jakobsberg, Sweden | Perverse mailers: rclaeson%erbe.se@encore.com Any opinions expressed herein definitely belongs to me and not to my employer.
jay@metran.UUCP (Jay Ts) (11/17/90)
In article <1990Nov15.192615.1238@hemel.bull.co.uk>, mpreen@hemel.bull.co.uk (Malcolm Preen) writes: > sparks@power.viewlogic.com (Alan Sparks) writes: > > >In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: > >>Using cpio instead worked just fine. Also, for backup purposes, > >>cpio is probably the best. It comes *standard* with the ability to > >>detect end-of-tape and create multi-volume archives. It has better > >>support for incremental backups and selective restores. And it supports > >>longer paths than tar's limit of 100 characters. I also prefer cpio, but none of these (IMO) are true for Xenix 2.2 and 2.3 systems. On Xenix, cpio's pathnames are limited to 128 chars, and if there are "too many [I love that explicit number :-) ] unique linked files, the program runs out of memory to keep track of them and thereafter linking information is lost." Maybe even with error messages :-) > > >Which version of cpio are you running? The cpio man page on the > >Sun here says, "cpio does not support multiple volume tapes." > >(unquote). > > On our system, Bull DPX/2-300 running a mix of system V and BSD the man page > for cpio says : > [discussion of -O and -I options supported on their system] Oh dear, all this brings a up a few more topics concerning cpio (and tar). I have been trying to write a "simple" shell script to give to my clients (mostly, well, *all* small company office workers) so they can easily back up their systems without knowing how to use the shell. They just select "Filesystem Backup" from their menu and follow the instructions. The problem is that I want the script system to run *unmodified* on any UNIX system, be it Xenix System V 286, 386; ISC 2.0, 2.2; ESIX or whatever. So far, tar and cpio seem to work differently on each system! I really prefer to use cpio due to the portability and versatility issues, but on Xenix, for example, the porting company just decided to support tar better than cpio. I guess there is a preference for tar at SCO; for both Xenix 286 2.2 and Xenix 386 2.3, cpio gets 2 manual pages and does not support *any* of the -I, -O or -M options. In addition, there is no mention of whether or not it can detect EOT and support multiple volumes. On these same systems, tar gets 5 manual pages, along with lots of options and support for multiple volumes (i.e., floppy disks. You specify the size of the "tape" on the command line, so EOT detection is not necessary.). On ISC and ESIX (both very close to AT&T Sys V/386), cpio and tar get nearly equal treatment. They are both documented as supporting multiple volumes. cpio is much more versatile, but due to lacking documentation, it is not clear exactly what cpio's behaviour will be at EOT unless certain options are used. For example, the -I -r -O option must be used with the -M option, but this is not clearly stated. (... I hope I am remembering this correctly ...) For -M, the manual says "[with -O and -I] ... you can use this option to define the message that is printed when you [sic.] reach the end of the medium. Well, I reached the end of *my* medium while trying to use the -M option as in cpio -ocavB -M "insert disk %d: " >/dev/tape' !!! The manual page does not say that -M will *not* work *without* -I or -O. In developing my "portable" script, I was trying momentarily to not use -I or -O to be compatible with SCO's cpio. Fortunately, I discovered this while using floppies; the resulting behaviour was that cpio reached the end of the disk, printed no message, and quietly flipped back to track 0 to continue with the "backup", (overwriting what was previously written, I guess) so it was immediately obvious to me that something was wrong. (3 Mb of files do not fit on a 1.2Mb floppy, do they?) This brings up another issue. Just because your documentation says cpio/tar will support multiple volumes, do you KNOW they really do? It's really up to your vendor's port and whomever's device driver(s) you are using. I commonly work on systems with, say, 40 Mb of disk usage and 60 Mb tapes. If my client's disk usage grows, I don't really know if there will be a message informing them that the backup will not fit on one tape. (It works on floppies, but what about the 3rd party QIC cartridges?) For the moment (and maybe forever) I do a listing of the tape, and compare it to the list I fed cpio, as in cd / find . -print >cpio.in [edit to eliminate the "./" at the start of each line of cpio.in] cat cpio.in | cpio -ocavB >/dev/tape cpio -ictB </dev/tape >cpio.out diff cpio.in cpio.out >diff.out if [ -s diff.out ] then print error message, ending in Call Jay Ts for help! else print success message fi There are also incompatibilities between ISC and SCO concerning what output is considered "error output" for the verbose listing, if I remember correctly from experience. I wanted to include an example here to illustrate, but don't remember the problem exactly, and reading the documentation just now got me very confused. It is not explicitly defined. The funny (?) part of this is that all of these (Xenix vs. ISC/ESIX) are sold (more or less) as "System V". I'm not even touching upon Berkeley/SunOS or whatever. And what about the "portable" script I was writing? Well, I gave up on that idea! I am now writing custom scripts (from scratch, each time) for each of my clients. It is actually a lot easier to support 10 fully-customized scripts than one "portable" one which is mostly "if then" statements, shell variable defines and other cryptic stuff that are only there to support nine other systems. These are clearly issues for the standards bodies. Until then, my best advice is to decide for yourself which of cpio and tar work best for you and your system, and try to be consistent! If another S.A. asks for something on tape, ask him/her which format to use, and clearly mark on any tape you write what the format is, maybe also providing a suggestion such as: "to restore: cd [dirname]; cpio -icdvmkB </dev/tape" (NOTE: If you're making a tape for me, please, if possible, use cpio with the -c option!) Also, I just want to mention that I feel that there are serious deficiencies in both cpio and tar, and there is work to be done to bring them even up to the quality of common MS-DOS backup utilities! I hate MS-DOS just as much as the rest of you, but when talking with my associates who use MS-DOS, I have to yield to them on this one. The major problems (as I see them): 1. Lack of verification - I can do a listing of a cpio tape, but that only checks the headers, not the files' contents. Both cpio and tar seem to have been implemented with the assumption that magnetic media are perfect! This should be listed in the BUGS section. Really! Does AT&T know that we are using these programs for backups? :-) 2. Speed - The UNIX-variants I've used are incredibly slow writing to floppies with cpio. I know UNIX is inherently slower due to double-copying of buffers between kernel and user space, but that just does not explain the difference! (If cpio is so slow because it is actually verifying writes, it's sure not documented. It also would make me wonder why I get so many bad archives on Verbatim Teflon-coated, pre- formatted floppies!) 3. User interface - need I say more??? You know as well as I do (I hope) what happens if you are on the 21st of a 23 floppy cpio, you get prompted "Insert disk 22: ", and you hit Enter *twice* by mistake. Errrrr!!! (Also, be forewarned that on Sys V/386, doing a backup through the sysadm menus will store the files on tape with ABSOLUTE PATHNAMES. Need I say more?) Well, this posting turned out to be quite long! I hope I've come close to putting an end to this issue, rather than causing more confusion (or starting another thread!). If not, I apologize in advance... Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
jessea@dynasys.UUCP (Jesse W. Asher) (11/19/90)
In article <529@comcon.UUCP>, tim@comcon.UUCP (Tim Brown) wrote the following: >In article <57@astph.UUCP>, joe@astph.UUCP (Joe Broniszewski) writes: >> Are there any advantages of using tar over cpio for doing backups? We >> -- >Tar seems more portable. I did some archives on a system running >ISC2.2 and could not read them on an Risc 6000/AIX machine. I suspect >that if I had remembered to use the -c option it would have worked >but tar works fine as is. I don't know about your version of tar, but mine will not back up zero length files or empty directories. Try tarring /usr/spool, erase it, and then try rebuilding it with what you have in your tarred file. You will be very aggravated(I speak from experience). cpio is much better in cases like these as tar will not get everything off the drive. I would use tar to archive data files together in one file(tarring source code together for transporting purposes, for example) and use cpio to do your backups. Otherwise you may run into situations where you will regret using tar. Jesse W. Asher Phone: (901)382-1609 6196-1 Macon Rd., Suite 200, Memphis, TN 38134 UUCP: {fedeva,chromc,rutgers}!dynasys!jessea -> Go climb a gravity well.
zsinwatt@qut.edu.au (James Watt) (11/20/90)
In article <1990Nov15.154616.27759@viewlogic.com>, sparks@power.viewlogic.com (Alan Sparks) writes: > Which version of cpio are you running? The cpio man page on the > Sun here says, "cpio does not support multiple volume tapes." > (unquote). > > -Alan > -- There is a utility called PAX available from SIMTEL-20 which reads and writes cpio and tar and supports multivolume tapes. As well as supporting the old formats it also supports POSIX extensions. I believe PAX conforms to IEEE 1003.2 standard. It will run on Suns. |--------------------------------------------------------------------| |AARnet: james@water.fit.qut.edu.au ARPA: ZSINWATT@QUT.EDU.AU | | | |SNAIL: James Watt, Technical Services Section, | | Faculty Of Information Technology, | | GPO BOX 2434, | | Brisbane 4001. | | | |Tel : (07) 223-2533 Int: +61 7 223-2533 | |Fax : (07) 229-1510 | |TZ : 10 hrs East GMT (GMT + 10) | | | |--------------------------------------------------------------------|
woods@eci386.uucp (Greg A. Woods) (11/22/90)
I've not paid tremendous attention to this thread up to now, but I don't recall anyone mentioning what I'm about to. In article <329@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > In article <1990Nov15.192615.1238@hemel.bull.co.uk>, mpreen@hemel.bull.co.uk (Malcolm Preen) writes: > > sparks@power.viewlogic.com (Alan Sparks) writes: > > > > >In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) quoted: > > >[.... and someone else, presumably writes ....] > > >>Using cpio instead worked just fine. Also, for backup purposes, > > >>cpio is probably the best. It comes *standard* with the ability to > > >>detect end-of-tape and create multi-volume archives. It has better > > >>support for incremental backups and selective restores. And it supports > > >>longer paths than tar's limit of 100 characters. >[ and I deleted some words about XENIX ] > Oh dear, all this brings a up a few more topics concerning cpio (and tar). >[....] > The problem is that I want the script system to run *unmodified* on any UNIX > system, be it Xenix System V 286, 386; ISC 2.0, 2.2; ESIX or whatever. So far, > tar and cpio seem to work differently on each system! >[....] > These are clearly issues for the standards bodies. Until then, my best advice > is to decide for yourself which of cpio and tar work best for you and your > system, and try to be consistent! If another S.A. asks for something on tape, > ask him/her which format to use, and clearly mark on any tape you write what > the format is, maybe also providing a suggestion such as: They [the standards bodies] are way ahead of you.... POSIX 1003.1 defines two portable archive interchange formats: extended tar, and extended cpio. POSIX 1003.2 Draft 9 / August 1989 defines a programme called "pax - portable archive interchange" which supports both of these formats. A third new format is under development to "address all restrictions and new requirements for security labeling, etc." It, and its resulting archives, are portable across many UNIX based, or POSIX compatible, systems. It definitely supports multiple volumes. It is extremely easy to use and very flexible. It can do the directory tree copying tasks of either tar or cpio with great ease as well. It is available today as freeware source code (commissioned by the IEEE for the 1003.2 standard). (v2.0 was posted some time ago to comp.sources.????) It is quite solid, and it works. I've had no trouble with it reading media written with older tar or cpio programmes. 1003.2 suggests the default output format to be implementation defined, and the available source defaults to USTAR. The default will likely be the new format, once it is defined. In some part of the pax source it mentions that "pax" is Latin for "peace".... > 1. Lack of verification - I can do a listing of a cpio tape, > but that only checks the headers, not the files' contents. If you can read the tape to get a directory, then the tape is OK, or else your device driver is broken or lying. Pax will identify clobbered files and attempt to skip to the next good one. If you are using some ancient hardware (such as maybe 9-track) that can't tell the difference between a good read, and a bad one, that's your tough luck. Seriously. If your backups are important, use known good media on a device that does lots of error checking in hardware. > 2. Speed - The UNIX-variants I've used are incredibly slow > writing to floppies with cpio. I know UNIX is inherently > slower due to double-copying of buffers between kernel and > user space, but that just does not explain the difference! Pax does nothing about double-buffering, though it will use *any* buffer size you want. If you have intelligent devices and/or device drivers, then you are off to the races with a good chance of winning. On the other hand, if you have a device which accepts maximum 8 Kb buffers, and slowly, such as the 3b2 CTC drive, you lose. However pax can read tapes created with ctccpio from this device, and survive bad blocks to boot. > 3. User interface - need I say more??? You know as well as I > do (I hope) what happens if you are on the 21st of a 23 floppy > cpio, you get prompted "Insert disk 22: ", and you hit Enter > *twice* by mistake. Errrrr!!! I think you'll find pax is far better than either tar or cpio.... As for the example problem you identify, the only good solution, beyond flushing the input buffer before reading important things, would be to have some form of volume header with a label on it. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA
duc@grumbly.COM (Richard Ducoty) (11/22/90)
mpreen@hemel.bull.co.uk (Malcolm Preen) writes: >sparks@power.viewlogic.com (Alan Sparks) writes: >>In article <1990Nov12.095657.22489@erbe.se> prc@erbe.se (Robert Claeson) writes: >>>Using cpio instead worked just fine. Also, for backup purposes, >>>cpio is probably the best. It comes *standard* with the ability to >>>detect end-of-tape and create multi-volume archives. >On our system, Bull DPX/2-300 running a mix of system V and BSD the man page >for cpio says : >......... > -I file > Read the contents of file as input. If file is a > ... > -O file > Direct the output of cpio to file. If file is a > ... ======================================= SVR4 also includes the I,O,.. switches for multi volume cpio. You have to be careful using these switches if the tapes, files, etc might be used on System V 3.2 or earlier System V machines. \\\ - - Richard Ducoty ..uunet!grumbly!duc _] Capitola, California duc@grumbly.com
tif@doorstop.austin.ibm.com (Paul Chamberlain) (11/26/90)
In article <1990Nov21.172717.16845@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >They [the standards bodies] are way ahead of you.... POSIX 1003.1 >defines two portable archive interchange formats: extended tar, and >extended cpio. POSIX 1003.2 Draft 9 / August 1989 defines a programme >called "pax - portable archive interchange" which supports both of >these formats. A third new format is under development to "address >all restrictions and new requirements for security labeling, etc." Is this third format the PAX native format? I seem to recall that PAX had a third format. This doesn't belong here but I'd like to urge the pax-makers to do some thorough testing of interoperability between DOS and Unix. I tried to use this for some serious and on-going file transfer and finally decided that I couldn't count on it. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
woods@eci386.uucp (Greg A. Woods) (12/03/90)
In article <4322@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: > In article <1990Nov21.172717.16845@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > >They [the standards bodies] are way ahead of you.... POSIX 1003.1 > >defines two portable archive interchange formats: extended tar, and > >extended cpio. POSIX 1003.2 Draft 9 / August 1989 defines a programme > >called "pax - portable archive interchange" which supports both of > >these formats. A third new format is under development to "address > >all restrictions and new requirements for security labeling, etc." > > Is this third format the PAX native format? I seem to recall that > PAX had a third format. No. The new format will most likely be incompatible with either of the two current formats. I don't have a copy of 1003.1, but I don't think enough has been published about the third format to allow an expermimental implementation. The pax we are running has only the two formats, though it has three user interfaces: tar, cpio, and 1003.2-pax. The default file format for the tar and pax interfaces is the extended tar format. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA "Political speech and writing are largely the defense of the indefensible"-ORWELL