Don Cragun <don.cragun at sun.com> wrote:
> The case has been recast as a fast track with timeout set to
> 12/03/2008. Note that this is delaying a fix for an escalation for a
> large external customer (whose name I cannot give on an alias with
> non-Sun participants).
I thought that for Sun quality is important...
Extending archive formats is something that should not be done in a hurry.
I did never extend the tar format before I was sure that I did not forget
important issues. Even the GNU tar people changed their sparse format
after I pointed them to the problem that results from storing the hole list
in the file metadata area.
I thought PSARC is to have a discussion to find the best solution.
> Note that a good portion of this discussion is about PSARC/2006/361;
> not about this case.
Well, I mentioned before and even before PSARC/2006/361 that I am willing to
offer my help. You could have aske me.
> >> I recommend to fix this by moving the hole information into the file data
> >> area,
> >> to switch to a offset/datasize notation (to reduce the size) and to write
> >> the information as comma separated pairs.
> >>
>
> That is not this case; you are asking to reopen 2006/361.
>
> The holesdata for cpio presented by this case is stored in the file
> data area as you are requesting; not in the header. However, the file
> size (including the holesdata) is still limited by the 11 octal digit
> c_filesize field in the cpio file header to a maximum size of 8Gb.
Even PSARC/2006/361 was integrated less than half a year ago (see previous
pax man pages that do notinclude the feature...)
Because the size of the cpio file data area is limited, I recommend to use
offset/datasize pairs to reduce the list size overhead.
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
