tar, split, burn to dvd result to tar file corruption
FedoraThis forum is for the discussion of the Fedora Project.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
tar, split, burn to dvd result to tar file corruption
I upgraded from fedora 7 to fedora 8. I started backing up the entire »/home« directory using Red Hat Magazine's Tips and Tricks: 'Splitting tar archives on the fly', because I use 4.7GB DVD+R medias and my »/home« size is over 5.5 GB.
»cat backupPART* >> /dev/stdout | tar -xzf /dev/stdin«
This makes no sense to me. First, why would you combine the files, append the result to /dev/stdout, and then attempt to pipe to tar? I don't even know what you would be piping....
Also, in "cat backupPART*", how do you know which one goes first?
How about:
cat backupPART00 backupPART01 | tar -xzf
My guess looking at your command line is the /dev/stdout stuff messed you up. It is very unsafe to do:
tar -czf /dev/stdout /home | split -d -b 40000 - backupPART
What if tar outputed an error message or warning? It would also go to stdout and mess up the binary bits.
You can try:
tar -vztf backupPART00
to see if it tells you anything.
Other than that all you can do is manually hack backupPART00.
Open it up in emacs binary mode or simply vi it to look for hints.
Since gzip looks at I think just a first few bytes to determine if the file is a gzip file, that means the problem is at the top of the file.
You might find a warning like:
"tar: Removing leading `/' from member names"
Just remove "tar: Removing leading `/' from member names" and you might get lucky assuming nothing else got written to stdout that messed up tar or the compression.
This makes no sense to me. First, why would you combine the files, append the result to /dev/stdout, and then attempt to pipe to tar? I don't even know what you would be piping....
I was positive about this. As an non-admin I'm not familiar with the behind the scene of piping. But I thought, 'cat' determines files and steps it's i/o units as file not as byte or line.
Quote:
Also, in "cat backupPART*", how do you know which one goes first?
Bash orders alphabetically (0-Z), I assumed.
Quote:
How about:
cat backupPART00 backupPART01 | tar -xzf
cat backupPART00 backupPART01 | tar -xzf -
stops also by
gzip: stdin: not in gzip format
tar: Child returned status 1
My guess looking at your command line is the /dev/stdout stuff messed you up. It is very unsafe to do:
tar -czf /dev/stdout /home | split -d -b 40000 - backupPART
What if tar outputed an error message or warning? It would also go to stdout and mess up the binary bits.
Indeed, that is what I assumed first of all, because while running tar creation of a 6 GB '/home'-directory I opened up a new (tabbed) terminal windows for listing (ls). I don't know if the output went to the same 'stdout-process' resp. split's stdin. On the other hand, the diagnostic and error messages stream stderr should not directed to split's stdin and the three streams (stdout,-in & -err) are attached to user's tty (should not interact with another open Terminal window).
Quote:
You can try:
tar -vztf backupPART00
to see if it tells you anything.
Unfortunatly, showing up the tarball file entries (tar -t) results to:
gzip: stdin: not in gzip format
tar: Child returned status 1
Quote:
Other than that all you can do is manually hack backupPART00.
tarfixer is not going to help since the problem seems to be with the compression.
If you have xxd try:
xxd backupPART00 | head -10
and past the results into a reply. That will at least provide a hint as to why it thinks this is not a gzip file.
If you do not have the xxd program, try:
head -1 backupPART00
This will not be that helpful and there is a chance that the binary might mess up the terminal, but if you do not have xxd it is the only simple thing I can think of to get a hint as to what the problem is.
But I thougth, the z option compresses only the data part of a tarball member not the entire tarball incl. member headers. (However, I'm not able to puzzle out the tar file format and tar's z-option vs. gzip-ping a tarball)
Editing:
The size of backupPART00 file is larger than the maximum Emacs buffer size, so Emacs cannot open the 4 GB file.
.
Last edited by fedusr; 11-28-2007 at 12:31 PM.
Reason: mistyped
So it does look like the output of an "ls" or something like that is corrupting the start of your backupPART00.
Because backupPART00 is so big it is hard to edit it.
Anyway to confirm that you even have a good gzip tar, I would do stuff like:
xxd backupPART00 | head -1000 | less
and look for 1f8b 0800. I guess you can also try:
xxd backupPART00 | grep "1f8b 0800"
to see if you have hope of editing the file. If you find "1f8b 0800" then you have hope of fixing the problem. You will probably have to find some binary editor (maybe bvi) that can handle such a huge file, or further break backupPART00 into parts, do the fix, and reassemble. Or maybe use dd skip=?? to skip everything up till the byte where "1f8b 0800" starts.
I'm able to replicate that messy tarball! When I run the tar creation & split command above, I added the --verbose (-v) option. All the verbose output - the copied files in full path names - did join split's <stdin>. But I do not understand the bahavior of 'tar'. It should be <stderr>, or not?
However, as you mentioned, all I have to do is to get rid off tar's copied files listing ('ls'-stylish) from my messed up tarball.
I haven't found a unix-like hex editor managing large files. The Java JHeditor crashed under icedtea & Sun's latest JRE. It would be a hard job editing a 6 GB file by ('search' &) hand. I going to try some scripts reading byte by byte and deleting strings starting with '/home/' and ending to <Linefeed>. Due to being a absolute Linux Newbie, I'll need some time to find out...
I'll report on sucess:-)
.
Last edited by fedusr; 11-30-2007 at 04:41 PM.
Reason: something forgotten
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
