Don Cragun writes: > >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.
I looked over that other case, and it seems that we discussed '--sparse' for pax as well as the GNUish compression scheme (in the absence of direct detection of holes), but not the cpio format itself. The unanswered question here is whether there's another way to encode holes in cpio stream format, and one that is used by other platforms. Apart from the detection question at the source side -- I agree that trying to "compress" files is a bit odd and certainly not the focus of this case -- are there other ways to encode them in the output format? If there are, then should we be deliberately incompatible? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
