Bug 172373 - "tar c archive.tar /dir" fails to create a consistent archive if it fails to read one input file
Summary: "tar c archive.tar /dir" fails to create a consistent archive if it fails to ...
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
high
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-03 14:23 UTC by Ville Herva
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-06 20:10:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Ville Herva 2005-11-03 14:23:44 UTC
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).


Now 
  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):
tar-1.15.1-10.FC4

How reproducible:
Didn't try

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


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 18:14:30 UTC
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 12:26:14 UTC

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.