I'm satisfied with your responses (but slightly saddened that we have to
spend effort into doing this when pax -- the POSIX standard archiver --
could probably be used instead.)
You can leave the case as automatic approval unless someone else has
other questions.
-- Garrett
Don Cragun wrote:
> 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
>>
