>Date: Mon, 24 Nov 2008 17:48:12 -0800
>From: "Garrett D'Amore" <gdamore at Sun.COM>
>
>Don Cragun wrote:
>>> Date: Mon, 24 Nov 2008 15:54:47 -0800
>>> From: John Plocher <john.plocher at gmail.com>
>>>
>>> On Mon, Nov 24, 2008 at 3:00 PM, Don Cragun <don.cragun at sun.com> wrote:
>>>     
>>>> 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.
>>>>       
>>> With this fix, these archives will no longer be "cpio format
>>> archives", but instead
>>> they will be "Sun Proprietary CPIO format archives".
>>>     
>>
>> Yes and no.  They are still standards conforming cpio format archives.
>> If cpio is asked to archive sparse files while using one of these new
>> -H option-argumments, the archive will contain entries for file types
>> that many archivers will not recognize.
>>
>> You may have noticed that the 1990 standard reserved three values
>> (C_ISCTG, C_ISLNK, and C_ISSOCK) that many implementations of cpio
>> could not handle at that time.  C_ISCTG is still reserved without
>> definition in the current standards.
>>
>>   
>>> That is, the customer will not be able to extract "holey" files as holey 
>>> files
>>> on non-Sun systems, rendering this a proprietary solution.
>>>
>>> Is there a plan to add this support to non-Sun archivers?
>>>     
>>
>> No.  Since cpio format archives are by definition limited to files
>> smaller than 8Gb, we aren't spending a lot of time extending and
>> supporting the format (other than for customer escalations like this
>> one).  There is enough detail in this case for others to recreate
>> sparse files in this format and to create archives containing sparse
>> files in this format if there is demand.
>>
>> The project team will add a note to the spio man page stating that the
>> -H ascii_sparse and odc_sparse option-arguments should not be used for
>> portable archives.
>>   
>
>Given these limitations, I wonder if it makes sense to mark these 
>options and the file format Uncomitted.  (Maybe you did in the original, 
>I don't recall.)  We have little other way that I can think of to 
>politely steer customers away from this and towards something that is 
>free from the limitations.  (Well, there is Committed Obsolete, I 
>suppose....)

I repeat:  There are no new options!  There is no new archive format!
There is only a new file type that may appear in archives that will be
used only if requested by new option-arguments to the current cpio -H
option.  Other than the 8Gb file size limit and other inherent
limitations of the cpio archive format, there is no problem supporting
these new file type entries in spio archives for the long term.

 - Don

>
>    -- Garrett
>
>

Reply via email to