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
