std-unix@ut-sally.UUCP (05/27/87)
From: gnu@hoptoad.UUCP (John Gilmore) In article <8128@ut-sally.UUCP>, akre@cuuxb.uucp (Mike Akre) writes: > Find knows how to not cross mount points in System V Release 3.0 and later. > It has a new option "-mount" that will restrict find's searching to the > filesystem containing the directory specified. SunOS 3.2 has a similar option, called "-xdev"; it says not to cross into a different device than the one on which the filename argument resides. As far as I can see, the two are the same. Ted Nolan (ted@usceast.uucp) posted diffs to Unix tar to add a "T" option to read filenames from standard input. However, his changes only worked for creating archives, not for reading from them. His changes were in net.sources posted 17 July 1984, as an "ed" script for editing 4.2BSD tar.c. I can provide copies if anybody wants 'em. I also generated a context diff from this and can provide that. It is true that my PD tar can read a list of filenames from standard input, for both creating and reading archives. It can also deal with a large list of names to extract even on a small memory system, by giving it another option letter indicating that the list on stdin is sorted to match the tape. I think that the argument boils down to: * Neither tar nor cpio is perfect for what we want. * People like cpio's user interface better. * Tar's format on the tape is more portable. As a standards effort, we can't just create a new "portable" format which is not portable to all the old Unix systems. If we claim the standard format is "cpio" or "tar" format, the old cpio or tar should be able to read it. All the suggestions for improving cpio format (Andy Tannenbaum's are a good example) ignore interchange with older systems. If we decide on a format which neither tar nor cpio, as they now stand, can read, let's invent a new name for the format and the command (posio, for portable standard I/O? That sounds too much like stdio though. Posar?). Personally I think what matters most is the interchange format, not the user interface; this is why I favor tar. The user or system implementer can always provide a better, or additional, user interface but they are stuck with the interchange format. As I recall, the draft I saw standardized the interchange format but specifically did not standardize the command used to generate that format. How would people feel about a compromise wherein a new option added to "cpio" would cause it to generate or read POSIX interchange tapes, which might happen to have a format compatible with V7 tar? Vendors could make this option the default if desired, requiring the user to specify an option to write binary or ascii cpio tapes. When reading, it could figure out the format of a tape without user intervention. Volume-Number: Volume 11, Number 36
dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/27/87)
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
I think one issue that needs to be clarified is: Are we trying to standardize
the user interface of the tar/cpio/other interchange standard, or the archive
format, or both? For example, although standard tar does not accept filenames
from standard input, that is irrelevant to the actual suitablity of its
archive format. The POSIX standard could easily use the tar archive format
with the cpio command structure, or vice versa.
[ POSIX is a programming interface standard. It has nothing to do with
the command interface. As such, the data interchange format is appropriate
for POSIX to standarize, but the user interface of the command that implements
it is not. While P1003.2 (Shell and Tools) might be interested in the
user interface, P1003.1 (POSIX) is not. -mod ]
The obvious choice seems to be the tar archive format (more widely used and
available) with cpio's user interface.
[ The user interface is irrelevant to P1003.1 and POSIX. The immediate
issue (that must be resolved before balloting on the POSIX Full Use Standard)
is what the data interchange format should be. Input before the next
P1003.1 Working Group meeting (20-24 June 1987 in Seattle) would be
most helpful. -mod ]
--
Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
Volume-Number: Volume 11, Number 40std-unix@ut-sally.UUCP (06/01/87)
From: <ihnp4!gorgo!bsteve> (Steve Blasingame) dhesi@bsu-cs.UUCP (Rahul Dhesi) Writes: >The obvious choice seems to be the tar archive format (more widely used and >available) with cpio's user interface. The significant issue regarding cpio that has not been addressed is the function of copying directory trees to directory trees. There is not another standard tool that performs this important function. [ I use tar to do this all the time. The 4.3BSD man page includes: Tar can also be used to move hierarchies with the command cd fromdir; tar cf - . | (cd todir; tar xf -) -mod ] Steve Blasingame (Oklahoma City) ihnp4!gorgo!bsteve Volume-Number: Volume 11, Number 46
std-unix@ut-sally.UUCP (06/02/87)
From: mark@cbpavo.mis.oh.att.com (Mark Horton) In article <8144@ut-sally.UUCP> gnu@hoptoad.UUCP (John Gilmore) writes: >* People like cpio's user interface better. > >* Tar's format on the tape is more portable. Personally, I feel exactly the opposite. The cpio format is quite portable, as long as you're careful to use the c option. The advantage to cpio format is that the images created are considerably smaller than tar's. Also, cpio can save/restore entries from /dev, making it useful for backups. [ The format in POSIX 10.1 can also do this. -mod ] The user interface, on the other hand, of cpio is horrible, unless you are trying to do an incremental backup. Compare the following equivalent commands: $ tar c . $ find . -print | cpio -oc > /dev/rmt8 $ tar x . $ cpio -icd < /dev/rmt8 Not only do you need a find command with cpio, but you'd better remember the c and d options, or you'll regret it later! cpio is a big win for incremental backups, as long as they fit on one reel of tape: $ find . -newer /etc/lastbackup -print | cpio -oc > /dev/rmt8 Of course, that's a pretty major "as long as", and there are lots of special versions of cpio that understand multiple backup volumes and streaming I/O and such things. Mark Volume-Number: Volume 11, Number 44