Re: how do I extract a 2.6 gigabyte .tar.gz file ?
"David B. Teague" <dbt@elentari.cs.wcu.edu> writes:
| On Tue, 27 Oct 1998, Gary L. Hennigan wrote:
|
| [snip]
|
| > | You might think that it would sit there chewing on the file for a bit
| > | before it got to some point beyond what it could deal with. Nope.
| > | Didn't even start -- failed to even open the file up.
|
| > No, compressed files have to be read entirely before being uncompressed.
| > Or at least that's a requirement of most compression schemes. Don't
| > recall the exact reason though. Something about storing the keys at the
| > end of the file?
|
| My experience with gzipped files is that if damaged, I can
| just zcat the file and have an initial segment which is usable.
|
| I made a test with a small tar file. It appears to me that tar files place
| information about where the file is to be placed along with magic numbers
| at the start of the file image in the tar file.
[snip]
That was an excellent idea, unfortunately Darxus has already tried
this and it didn't work for him. Perhaps gzip tries to read the whole
file and even though, in your case, the file is truncated it'll do
what it can. In Darxus' case that means it's trying to read past the
2GB limit and that's a no-no under 80x86 based Linux systems.
However, now knowing that gzip will in fact decompress a file that's
lost it's tail, Darxus could try to write a little C program that calls
truncate() to truncate his file to around 2GB (a little less might be
a good idea) and see what he can do with it.
Of course I'd treat this idea as a last resort. I have NO idea if
Darxus can copy that file, for a backup before trying the truncate()
thing, and it'd be a Bad Thing (TM) if he truncated the existing file
only to find out it wouldn't work. Plus, I don't know if truncate()
will work on a file greater than 2GB?
Gary
Reply to: