This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 179507 - tar incompletely extracts file created with --sparse option
tar incompletely extracts file created with --sparse option
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-31 17:03 EST by Ed Swierk
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-06 06:24:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
fix candidate (1.14 KB, patch)
2006-02-02 08:09 EST, Peter Vrabec
no flags Details | Diff
next candidate (918 bytes, patch)
2006-02-03 09:07 EST, Peter Vrabec
no flags Details | Diff

  None (edit)
Description Ed Swierk 2006-01-31 17:03:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051201 Fedora/1.5-1.1.fc4.nr Firefox/1.5

Description of problem:
Extracting a sparse file to a filesystem like vfat that does not support sparse files results in an incomplete output file.  tar prints a warning but exits with a 0 status code.


Version-Release number of selected component (if applicable):
tar-1.15.1-11.FC4

How reproducible:
Always

Steps to Reproduce:
# echo helloworld >sparse
# dd of=sparse bs=1K seek=512 count=0
# tar -c -S -f sparse.tar sparse
# mkfs.vfat -C vfatfs 1024
# mount -o loop vfatfs /tmp/mnt
# tar -x -o -f sparse.tar -C /tmp/mnt
tar: sparse: Warning: Cannot truncate: Operation not permitted
# echo $?
0


Actual Results:  The output file contains only the first 512 bytes of the input file.


Expected Results:  The contents of the output file should be identical to the input file, even though it will of course occupy more space on a filesystem that does not support sparse files.

If calling ftruncate() returns EPERM, which seems to be the case here, tar could instead expand the file to the proper size by writing zeros.  If this is undesirable as default behavior for some reason, perhaps an option can be added to ignore the "sparseness" of a file, similar to the --no-same-owner option for ignoring owner information.

At the very least, tar should not generate incorrect output and then return a 0 status code.


Additional info:
Comment 1 Peter Vrabec 2006-02-02 08:09:58 EST
Created attachment 124047 [details]
fix candidate

Could u check this patch, please. I gonna send it to upstream too.
Comment 2 Ed Swierk 2006-02-02 16:58:20 EST
The patch works perfectly.

The truncate warning doesn't seem relevant now that there's a Plan B.  Arguably
the user might want to know that a sparse block was filled in with zero data,
but since no warning occurs when the block is somewhere other than at the end of
the file, printing a warning here seems extraneous.
Comment 3 Peter Vrabec 2006-02-03 09:07:20 EST
Created attachment 124105 [details]
next candidate

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