>Date: Mon, 24 Nov 2008 14:59:19 +0100
>From: Joerg.Schilling at fokus.fraunhofer.de (Joerg Schilling)
>
>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.
Your star archiver uses extended headers to encode the holes data.
There are no extended headers in cpio format archives. The customer
insists on cpio format archives.
>
>> >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?
You're correct. I didn't go back to the 1990 POSIX.1 standard after
reading the rationale in the current standard. Until I went back and
looked at it this afternoon, I thought the requirement was to extract
an unknown file type in any archive format as a regular file and to
print a diagnostic message saying that the conversions to regular file
had been done. Our current cpio and pax convert files of unknown type
to a regular file, but don't print a diagnostic. When this case is
approved, a bug report will be filed so cpio and pax will print a
diagnostic in this case no matter what archive format is being read.
>
>
>> >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.
But this uses ustar/pax format archives. That won't satisfy the
customer for that filed the escalation to get this fix. They insist on
a fix using cpio format archives.
>
>BTW: Sun pax does not have the ability to support sparse files (see man page).
As seen in later email, Sun pax does support sparse files.
- Don
>
>J?rg
