Re: [Bug-tar] Incorrect listing of sparse files with more than 8G of real data

[Pavel Raiskup]

Hello Chris,

On Saturday 25 of October 2014 21:08:38 Niessen, Chris wrote:
> If a sparse file with more than 8G of real data is stored in a POSIX
> format archive (which is done correctly in 1.28), listing the contents
> of the archive will fail.

[SNIP]

> A patch to address this was submitted against 1.27
> http://www.mail-archive.com/bug-tar%40gnu.org/msg03905.html
> but it doesn't seem to have made it in to 1.28.

correct thread, but better link is:
http://www.mail-archive.com/bug-tar%40gnu.org/msg03910.html
.. which iterated to:
http://www.mail-archive.com/bug-tar%40gnu.org/msg03917.html

The last patch deals with realsize/size once *all* extended headers are
decoded - thus the order of 'GNU.sparse.realsize' vs. 'size' extended
haders does not matter.

> Before finding that patch, I generated my own that modifies size_decoder
> to put the value of the "size" extended header value into
> archive_file_size

I understand so far, however ..

> , and if archive_file_size and stat.st_size have the
> same value (meaning stat.st_size hasn't been updated by a previously
> parsed extended header), then the "size" attribute will also get put
> into stat.st_size.  That way, stat.st_size will be updated properly for
> non-sparse files, but will not be clobbered for sparse ones.

... I'm getting lost here because you *now* assigned a value to the
archive_file_size.  In this case, the 'stat.st_size' may already be set
(a) by the parsed ustar header and (b) also re-asssigned once more by
extended header 'GNU.sparse.realsize' (if it was decoded before 'size'
ext. header) but why the 'stat.st_size' and 'archive_file_size' should
have the same value if you changed one of those?

Pavel