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:
Created attachment 124047 [details] fix candidate Could u check this patch, please. I gonna send it to upstream too.
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.
Created attachment 124105 [details] next candidate