Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 172373 - "tar c archive.tar /dir" fails to create a consistent archive if it fails to read one input file
"tar c archive.tar /dir" fails to create a consistent archive if it fails to ...
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-11-03 09:23 EST by Ville Herva
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:
Last Closed: 2005-11-06 15:10:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ville Herva 2005-11-03 09:23:44 EST
From Bugzilla Helper:
User-Agent: Opera/9.0 (Windows NT 5.1; U; en)

Description of problem:
I created a backup of a directory that had one file that was not completely 
readable (IO error from the block device). The size of the files was ~4GB. 

I did 
  tar cvf /mnt/elsewhere/archive.tar /mnt/msdos

tar said:

/mnt/msdos/Program Files/file1002
/mnt/msdos/Program Files/file1003
/mnt/msdos/Program Files/file1004
/mnt/msdos/Program Files/file1005
tar: /mnt/msdos/Program Files/file1006: File shrank by 692300 bytes; padding 
with zeros
/mnt/msdos/Program Files/dir2/file2000
/mnt/msdos/Program Files/dir2/file2001
/mnt/msdos/Program Files/dir2/file2002
/mnt/msdos/Program Files/dir2/file2003

and continued til the end listing all the files (afaik). The archive.tar ended 
up at around 4GB (about right).

  tar tf archive.tar 
only lists files up until /mnt/msdos/Program Files/file1006 - NOTHING after it. 
tar vzf also doesn't extract more than 600MB (ends where file1006 appears). "
tar x" or "tar t" goive no error, though.

Unfortunaly, I already wiped the erraneous input file system (falsely trusting 
the tar backup I had), so I can't retest.

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1. "tar c" on a file system with an unreadable file.

Actual Results:  Missing everything after the unreadable file

Expected Results:  Zero padded unreadable file; complete archive otherwise

Additional info:
Comment 1 Ville Herva 2005-11-03 13:14:30 EST
I got a response from bug-tar@gnu.org suggesting that this is ficed in newest 
snapshots. See http://lists.gnu.org/archive/html/bug-tar/2005-11/

I was able to salvage a similarily damaged (in fact, the same) fs from a        
backup. This is a mildly (fixable by fsck.vfat) fat fs corrupted by a power     
interrupt - only few files give IO error.                                       
I downloaded and built tar-1.15.2-20050902 from                                 
ftp://download.gnu.org.ua/pub/alpha/tar. I verified that tar (GNU tar)          
1.15.1 from tar-1.15.1-10.FC4 reproducibly exhibits this bug whereas tar        
(GNU tar) 1.15.2 from tar-1.15.2-20050902.tar.bz does not.                      

Comment 2 Ville Herva 2005-11-06 07:26:14 EST

I confirmed that tar-1.15.1-11 from rawhide fixes this with my test case.

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