Bug 1024268 - tar --sparse silently corrupts files on filesystems where non-empty files may have zero blocks
Summary: tar --sparse silently corrupts files on filesystems where non-empty files may...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tar
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Pavel Raiskup
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On: 1024095
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-29 09:30 UTC by Pavel Raiskup
Modified: 2015-11-18 14:00 UTC (History)
8 users (show)

Fixed In Version: tar-1.26-27
Doc Type: Bug Fix
Doc Text:
Clone Of: 1024095
Environment:
Last Closed: 2014-06-13 12:30:39 UTC
Target Upstream Version:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.