I'm attaching a test script. This happens at least with GNU tar 1.15.1 on x86. When 'S' command-line switch is removed, tar will perform as expected.
Created attachment 61717 [details] Testing script First pass creates a sparse tar file. Extraction is incorrect. Second pass creates a normal tar file. Extraction is fine. The second pass requires 4G of HDD space.
Tested under reiser4 and reiserfs. ====== From documentation ====== The following table summarizes the limitations of each of these formats: Format UID File Size Path Name Devn gnu 1.8e19 Unlimited Unlimited 63 oldgnu 1.8e19 Unlimited Unlimited 63 v7 2097151 8GB 99 n/a ustar 2097151 8GB 256 21 posix Unlimited Unlimited Unlimited Unlimited ====== From tar --help ====== *This* tar defaults to: --format=gnu -f- -b20 --rmt-command=/usr/sbin/rmt
can you please e-mail this issue to the bug tar list ? you'll get a lot more help a lot faster if you do so ... http://lists.gnu.org/mailman/listinfo/bug-tar
SpanKY: ok, I've just sent it with a reference to gentoo bugzilla page. Thanks !
Response from upstream developer: > I've had a serious issue when backing up large sparse files with tar > 1.15.1. This has been fixed in CVS. Thanks for reporting. Regards, Sergey
ok, i'll look through upstream cvs and see if i can find/grab the fix for this thanks
Created attachment 61813 [details, diff] sparse.patch
Created attachment 61814 [details, diff] xheader.patch
could you try these patches and see if one or the other (or both) fix the issue ?
Thanks ! Unfortunately I've tried applying the two patches, both together and separately, and they don't solve the problem..
tested this, problem no longer exists.
