Info is nice, I didn't know Info:-)
Quote:
Originally Posted by
Perderabo
...
Problem one: "/home" probably appears somewhere in the good part of the archive and your solution would then drop bytes from the archive.
Actually I applied gzip ('z' option). I have a gzip'ed archive
salted by file listings at random. A gzip'ed archive is like any gzip'ed file. Tar's listings didn't flow through the gzipper, I think. I assume that the gzipped (tar) file data is in good order, but plain tar's listings are randomly spread over the gzipped file.
Quote:
Originally Posted by
Perderabo
...
Problem two: The output of the listing was probably buffered because it was going to a non-tty, so blocks of lising may be interspersed and you may have lines split between blocks. So "/home/this/that" might not have fit in the buffer. So "/home/th" was put in and the buffer was written. Then "is/that{lf}" is placed in the buffer. But meanwhile output buffers of the archive are being written.
Yes, I understand. The tar listing entries are cut resp. '/home/az/...[a-Z]...<LF>' can't be applied as a kind of search string.
Quote:
Originally Posted by
Perderabo
..., but I doubt that the archive can be salvaged.
On the other hand, the problem is reduced to identify the bad bytes consisting of tar's instiled file names in my messy backup file. I don't see why it should not be possible in principle. I don't know about the gzip algorithm or the gzip file format. Maybe there are checksums, byte set ranges or something like that is useful for recovery.
However, are there any compression recovery kits available (based on zlib)? I've found 'grzrecover', but it's crashing on my file:-)
Thank you.