[Bug-cpio] Extract Problem

[lewis . lisenby]

Hi,
Our application uses HSM (Computer Associates) to write data to a tape in
sessions.  Our application runs on Solaris 2.5.1 and the tapes we are using
are DLT and 9840 type in StorageTek's libraries.  Every file written has a
corresponding hard link with it.  We can read all files on a session on the
tape by using Solaris' cpio command:

# cpio -iduv -C 32768 < /dev/rmt/1cbn

This will dump all files on the session and I should see output on my
screen similar to:

080020c45b86.3ed9733e003cc6.7bafaf
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l6_2003-05-31_22:30.00001 linked
to 080020c45b86.3ed9733e003cc6.7bafaf
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l6_2003-05-31_22:30.00001
080020c45b86.3edac52e04aa07.2f4a63
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l0_2003-06-01_22:30.00001 linked
to 080020c45b86.3edac52e04aa07.2f4a63
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l0_2003-06-01_22:30.00001
1052800 blocks

The data actually dumped to the disk will look something like:

# ls -li
1755568 -rw-r--r--   2 root     root     5218304 Dec 25 07:49
080020c45b86.3ed9733e003cc6.7bafaf
1755569 -rw-r--r--   2 root     root     243421184 Dec 25 07:49
080020c45b86.3edac52e04aa07.2f4a63
1769052 drwxr-xr-x   3 root     other        512 Dec 25 07:49 PATHNAMES

I decided to try the GNU version of cpio to see how it worked.  I
downloaded version 2.4.2 from sunfreeware.com as a test.  When I executed
the "cpio -iduv -C 32768 < /dev/rmt/1cbn" command the output to the screen
seemed good but when I checked the actual files on disk I saw:

1787045 -rw-r--r--   4 root     root     5218304 Dec 25 07:50
080020c45b86.3ed9733e003cc6.7bafaf
1787045 -rw-r--r--   4 root     root     5218304 Dec 25 07:50
080020c45b86.3edac52e04aa07.2f4a63
1798122 drwxr-xr-x   3 root     other        512 Dec 25 07:50 PATHNAMES

As you can see from the inode numbers, the second file is being hard linked
to the first.  I checked the actual data in the first file and it is
correct but I don't understand why the second file is being linked to the
first.  All files within the PATHNAMES directory are also linked to the
first file, although only one should be.  I went to other sessions with
more files and did this same test and got the same result.  The first file
written is correct and then all successive files written afterwards appear
to be read, but when you look at the file listing they're all hard links to
the first file.

I then tried to just dump one file using GNU's cpio instead of dumping the
whole session:

# cpio -iduv -C 32768 "080020c45b86.3edac52e04aa07.2f4a63" < /dev/rmt/1cbn

The above file I dumped is the second file from the earlier test.  The data
dumped to the disk was correct in this scenario:

# ls -li
1823880 -rw-r--r--   2 root     root     243421184 Dec 25 07:49
080020c45b86.3edac52e04aa07.2f4a63

This implies to me that I'm only able to properly dump the file from tape
using GNU's cpio if I know the name of the file.  I checked what cpio
thought the file should look like by doing:

# cpio -itv -C 32768 < /dev/rmt/1cbn

I got the following on my screen:

-rw-r--r--   2 root     root      5218304 Jul  5 05:24
080020c45b86.3ed9733e003cc6.7bafaf
-rw-r--r--   2 root     root            0 Jul  5 05:24
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l6_2003-05-31_22:30.00001
-rw-r--r--   2 root     root     243421184 Jul  5 05:24
080020c45b86.3edac52e04aa07.2f4a63
-rw-r--r--   2 root     root            0 Jul  5 05:24
PATHNAMES/CI/am/blobs/backups/ostore_bkp_l0_2003-06-01_22:30.00001
16450 blocks

So, the content listing looks good but when I go to actually dump the data
and I don't explicitly name the file I'm dumping, I get the wrong results.
Is there a different switch I should use?  Am I doing something wrong?  I
did all of the above on a Linux machine and got the same results as well.


Lewis Lisenby
Technical Support Engineer
Eastman Kodak Health Imaging Division
6200 Tennyson Parkway
Plano, TX  75024
800-328-2910
K-NET: 524-1657
Direct: 972-805-1657
Fax: 972-805-1455
E-mail: address@hidden