My documentation for "newc" is based primarily on studying the
implementation of GNU cpio.  I've not found any good
references for the history of this format.

I'm a little unclear what pax implementation you're
discussing.   Based on the description below, I would
suggest you test whether this program duplicates bodies
for each hardlink it stores.  This is easy to test:  Make
two hardlinks to the same large file, archive them
and see if the resulting archive is twice as big
as the file.  The "odc" (POSIX-1988) format should
duplicate bodies for hardlinks.  GNU cpio's implementation
of "newc" format does not.  Tar formats (including
the POSIX-2001 pax extended format) do not as a rule,
though the pax extended format does permit it as an
option.

My sympathies for the maintainers of the pax you're
discussing; it is surprisingly difficult to correctly
handle all three common approaches for hardlink management
within a single program.

Tim Kientzle


Daniel Kahn Gillmor wrote:
Tim Kientzle of FreeBSD (author of libarchive, attempting to CC here)
describes the cpio format here:

 http://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt

This document states about the SRV4 (newc) format (magic 070701, which
is what we're dealing with):

     In this format, hardlinked files are handled by setting the
     filesize to zero for each entry except the last one that appears
     in the archive.

So this is interpretation is shared by at least GNU and FreeBSD,
afaict.

pax appears to be in disagreement with these systems as far as its
creation of SRV4/newc archives goes, since it stores a non-zero
filesize for each entry of a hardlinked file.  It's in dangerous
disagreement with GNU and FreeBSD during the unpacking stage, because
it re-creates hardlinked files as 0 bytes in length if it encounters
archives created by the other utilities.

Hope this is a useful reference,

        --dkg

For Tim's reference: we're discussing pax here:
http://bugs.debian.org/42158




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to