On Feb 6, 2011, at 1:56 PM, Joerg Schilling wrote: > Tim Kientzle <t...@kientzle.com> wrote: > >>> >>> If GNU tar archives sparse files, it creates archives that violate the >>> POSIX structuring conventions for TAR archives. >> >> The newer GNU tar --posix support addresses this, though >> it's not (yet?) the default format for GNU tar. I think the >> current "1.0" variant is pretty well thought out (though I do have >> a couple of small quibbles. ;-) >> >> Libarchive now supports the GNU tar --posix "1.0" variant when >> writing sparse files. > > I am not sure what you understand by posix version 1.0. The first GNU tar > implementation that did move the hole description data into the POSIX > extended > headers ...
This is the format documented by GNU tar as their "0.0" sparse variant. > I asume that the current variant thus cannot be called "1.0". It is different > and IIRC, it contains has a very long line of hole/data pairs. This is the format documented by GNU tar as their "0.1" sparse variant. The current format (which GNU tar documents as the "1.0" sparse format) stores the hole/data information in a block prepended to the file data. In particular, this makes it possible to extract a sparse file to disk with a tar program that does not understand the extension, then post-process the files on disk. (My one real quibble: When extracted by tar programs that don't understand the extension, the resulting files on disk lack any file signature to indicate the wrapper format.) It has been a while since I looked at the star approach, but it sounds very similar to the current GNU tar approach. Tim
