Hide Forgot
+++ 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. ..snip.. 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 20b4497c7bdc00effbb5ad65d04a3bc3 tar.sparse.broken.file c54104d7894a1941ca710981da437f9f 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: http://git.savannah.gnu.org/cgit/tar.git/commit/?id=a9895fd20c957ce184091672f1623a5bedd82407 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.
http://bulk-mail.corp.redhat.com/archives/cvs-commits-list/2013-November/msg05963.html
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: https://lists.gnu.org/archive/html/bug-tar/2013-10/msg00030.html