+++ This bug was initially created as a clone of Bug #1024095 +++
Description of problem: When I create tar archives with the --sparse flag, some
files are corrupted silently. I do not see this bug in 1.23, but it is present
in 1.26 and in 1.27.
bash-4.2$ tar --sparse -cf - tar.sparse.broken.file | tar -C out --sparse -xpBf -
bash-4.2$ ls -l tar.sparse.broken.file out/tar.sparse.broken.file
-r--r--r-- 1 ajs ead 35 Oct 28 15:12 out/tar.sparse.broken.file
-r--r--r-- 1 schorr ead 35 Oct 28 15:12 tar.sparse.broken.file
bash-4.2$ md5sum tar.sparse.broken.file out/tar.sparse.broken.file
--- Additional comment from Andrew J. Schorr on 2013-10-28 22:06:31 CET ---
This patch reverts the shortcut added here to decide that a file is empty if
st_blocks is zero:
On some filesystem such as Netapp, small files are contained in the inode and
have st_blocks set to zero. So this test is not reliable.
I'm not sure if we support in RHEL7 inlining for any of our file systems, but I
would say that even if we do not, this is worth to fix for RHEL7.
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
ext4, btrfs and ntfs_3g all report non-zero st_blocks for inlined files (see mainline commit 9206c561554c948111d3cf6fc563a0beaaf790b3 for ext4) -- did anyone contact netapp to see if they think they should make a similar fix?
I haven't done so. Feel free to report. Tar has been fixed to take this
(possibly wrong?) FS behavior into account.
Btw., GNU tar upstream thread is here: