Bug 1024268

Summary: tar --sparse silently corrupts files on filesystems where non-empty files may have zero blocks
Product: Red Hat Enterprise Linux 7 Reporter: Pavel Raiskup <praiskup>
Component: tarAssignee: Pavel Raiskup <praiskup>
Status: CLOSED CURRENTRELEASE QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: aschorr, john.haxby, jpopelka, jscotka, kdudka, ovasik, praiskup, psklenar
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tar-1.26-27 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1024095 Environment:
Last Closed: 2014-06-13 12:30:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1024095    
Bug Blocks:    

Description Pavel Raiskup 2013-10-29 09:30:10 UTC
+++ 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.

Comment 1 Pavel Raiskup 2013-10-29 09:32:09 UTC
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.

Comment 7 Ludek Smid 2014-06-13 12:30:39 UTC
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.

Comment 9 john.haxby@oracle.com 2015-11-18 10:30:31 UTC
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?

Comment 10 Pavel Raiskup 2015-11-18 14:00:48 UTC
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