Red Hat Bugzilla – Bug 172373
"tar c archive.tar /dir" fails to create a consistent archive if it fails to read one input file
Last modified: 2007-11-30 17:11:16 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.
tar cvf /mnt/elsewhere/archive.tar /mnt/msdos
tar: /mnt/msdos/Program Files/file1006: File shrank by 692300 bytes; padding
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):
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
I got a response from firstname.lastname@example.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.
I confirmed that tar-1.15.1-11 from rawhide fixes this with my test case.