Re: [Bug-tar] Interchange/performance issue with archive containing sparse file

[Tim Kientzle]

On Feb 6, 2011, at 1:56 PM, Joerg Schilling wrote:
> Tim Kientzle <address@hidden> 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