cpio 2.4.2 bug?

[H.J. Thomassen]

Hello,

We use GNU-cpio 2.4.2 and have the following problem:

Short:
Assume I have a directory with two filenames, which are
hardlinks to the same i-node. I make a crc-cpio archive
with both files; then I selectively recover one of the
files back from the archive. I get a zero-length file if
the name I choose for recovery is not the last one in the
archive (i.e. if my name is not the name where the data
have been hooked onto in the archive).

Step by step demo:
   $ ls -li name[12]
   1204536 -rw-rw-rw-   2 hjt hjt  1308 Jan 10 16:54 name1
   1204536 -rw-rw-rw-   2 hjt hjt  1308 Jan 10 16:54 name2
When I make a crc-type cpio archive, the actual data are only
stored once (attached to the last of the link names):
   $ ls name[12] | cpio -ov -Hcrc > arch
   name1
   name2
   4 blocks
   $ cpio -itv < arch
   -rw-rw-rw-   2 hjt      hjt             0 Jan 10 16:54 name1
   -rw-rw-rw-   2 hjt      hjt          1308 Jan 10 16:54 name2
   4 blocks

I understand that this single storage is new since cpio 2.3.2;
In my opinion it is an improvement. But look what happens now:

   $ rm name[12]             # remove both old disk files
   $ cpio -iv name1 < arch   # selectively ask "name1" back
   name1
   4 blocks
   $ ls -li
   1204538 -rw-rw-rw-   1 hjt hjt     0 Jan 10 17:47 name1
                                Length zero!

It seems to me that the algorithm in copyin.c assumes that the
"name2" will always pass by eventually, and does not count on
the fact that higher levels stop the execution when the name-list
is exhausted. It may be a nasty surprise to the user.

---
Hendrik-Jan Thomassen
<address@hidden> http://www.ATComputing.nl/images/pasfotos/hjt.jpg
AT Computing    P.O. Box 1428   6501 BK Nijmegen    The Netherlands
Office tel.+31-24-3527252 (fax +31-24-3527292)
Home   tel.+31-24-3446250 (fax +31-24-3441298)