Garrett,
Please find comments in-line below...
-Don
>Date: Fri, 21 Nov 2008 16:07:47 -0800
>From: "Garrett D'Amore" <Garrett.Damore at Sun.COM>
>
>A few questions, which probably mean that this case should be promoted
>to a fast track.
I have seen several automatic cases that have had a few questions asked
and answered without changing status. If you aren't satisfied with the
responses you get to your questions, I'll change the status.
>
>1) Given that this requires new flags to be added (as well as creates a
>new file format), is there a compelling reason to add these flags rather
>than just telling folks who want holey file support to use pax? (I
>guess this is a level 0 question... it seems like pax does everything
>cpio does, only more?)
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.
>
>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.)
>
>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
file. With the data in the file, the original file can be
reconstituted. (I should say that the standards did require this, cpio
and tar were in XPG3 and SVID3; but were replaced by pax in POSIX.2 back
in 1992. Our tar and cpio still meet the requirements of those older
standards.)
>
>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.
>
> -- Garrett
