In article <ccd99f9a.0309091416.5e8fd8c2@posting.google.com >,
TCMa <ma77777777772000@yahoo.ca> wrote:
>I want to write and read a small text file (50-200 bytes) to/from the
>beginning of a tape. Then I use ufsdump and ufsrestore to write and
>read several partitions of the disk to/from the same tape.
>e.g.
>ufsdump 0uf /dev/rmt/0cn /dev
>ufsrestore rf /dev/rmt/0cn
>
>What is the command to write and read the small text file to the
>beginning of tape?
>
>Should I use the cpio command?

The cpio command cannot really be recommended since many years.

- CPIO is not an extensible format. If you like to extend it,
you need to define a new incompatible format. This already
has been done twice! The first format (from around 1975) was
binary and had massive portability problems after UNIX
has been ported to other platforms than the PDP-11. You cannot
even autodetect byte oder unless the first file name has an
odd number of characters.

- The second format from around 1985 but limits
UID/GID to 262143 and only allows 18 bits for major/minor.
Major/minor is not split which may give problems.
The max file size is 8 GB

- The third format if from 1989 (SVR4).
It entents uid/gid to 32 bits, has split major/minor
but limits the file size to 2 GB. So this was a partial
step backwards :-(

- Most cpio programs have massive problems with hard links
because there is no file name based mapping. Instead the
detection is based on st_dev and st_ino and some bits
are mapped off before archiving. As most cpio implementations
do not create virtual mapped inode numbers, 'funny' things
happen if there are hard links.


- No CPIO format contains the user/group name which gives
problems if you need to transport date to systems with
diferent id/name mapping.


- As the three CPIO formats are completely non interchangeable
nothing may be read if the currenly found format is not
supported by the extraction program. As a POSIX compliant
program only needs to support the second one, you may
imagine yourself what happens if you don't know this
in advance....

Tar is much more forgiving.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily