Don Cragun <don.cragun at sun.com> wrote:
> There are no new options (aka flags); there are just new values for the
> -H option arguement.
>
> These changes to cpio are to fix an escalated bug report from the Live
> Upgrade project. The submitter insists on using cpio; not pax. The
> project team would be happy to deprecate tar and cpio, and to use pax
> as a replacement, but tar and cpio provide a few features that aren't
> yet duplicated by pax and the project team's priorities are to work on
> escalations and porting packages to Nevada; not to improve
> infrastructure of existing utilities.
A strong reason for going to star. Star implements all available features
in it's "star" personality.
> >2) (This is probably stylistic.) Why two different flags (ascii_sparse
> >and odc_sparse)? Couldn't you just add one new flag for sparse support,
> >and then figure out whether ascii or odc by the presence of the -H odc flag?
>
> The number of available option letters (or flags) that aren't used by
> Solaris cpio, GNU cpio, and star is extremely limited. And, we try to
> avoid adding options that use the same option letter with different
> meanings between the various archivers. (We try, but we don't always
> succeed. Here it was easy to use -H option arguments to identify
> different archive formats rather than add a conflicting option.)
Introducing "archive formats" that cannot be properly detected from reding the
first archive header from a random archive has been done in the 1980s.
This is now 20 years later and we schould only define archive formats that
allow to be properly detected.
> >3) My interpretation of the last sentence in section 4 ("Archivers that
> >do not recognize the sparse file mode bit will restore the compressed
> >file and its prepended data as a regular file.") is that the resulting
> >destination file will be quite different from the source -- it will not
> >have holes, but neither will it be zero filled, and it will have the
> >prepended information string stored instead. Correct?
>
> Yes. The additional mode bit makes it an unrecognized file type for
> archivers that don't know what is going on. The standards require that
> when an unrecognized file type is found, the data be stored as a regular
This is defined for tar based archive formats but not for cpio.
For cpio archives (see SUSv2), the standard just mentiones that archives that
contain "additional file types" should not be transported to other systems.
Will the man page include a hint on the portability issues?
> >4) Is there any other convention or standard for holey cpio archives in
> >common use? (E.g. something supported by Linux or star?)
>
> This was discussed while we were working on PSARC/2006/361. Some other
> archivers have a --sparse long option that converts sequences of zero
> bytes into holes. The ARC gave explicit direction to the project team
> that archivers should "preserve" existing holes, not try to reduce disk
> usage by "creating" holes. None of the other archivers (except for our
> pax) have the ability to preserve existing holes in sparse files. I
> see no reason why that advice should be true for pax, but not for cpio.
Star implements -sparse (in create mode) and -force-hole (in extract mode).
Star is the first archiver that allowed to correctly preserve existing holes
in sparse files. Support for exact replication of sparse files has been
implemented in June 1998. Sparse support in general is present in star since
1993/1994.
BTW: Sun pax does not have the ability to support sparse files (see man page).
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
