[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] new/old extract problems with 6GB sparse file
From: |
Paul Eggert |
Subject: |
Re: [Bug-tar] new/old extract problems with 6GB sparse file |
Date: |
Mon, 19 Jun 2006 14:52:14 -0700 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
Joerg Delker <address@hidden> writes:
> Is that because the extract logic is just not "aware" of this problem,
> or because there was already data loss during creation?
Could be either, as far as I can tell. (I haven't investigated
thoroughly.)
> If I compare this to my archive, this doesn't match your comments:
> 0000600 \0 \0 0 0 0 0 0 0 0 0 0 0 0 \0 0 0
> 0000620 0 0 0 0 0 7 0 0 0 \0 0 0 0 0 0 0
> 0000640 2 0 0 0 0 \0 0 0 0 0 0 5 1 0 0 0
> 0000660 0 \0 0 0 0 0 0 5 6 0 0 0 0 \0 0 0
> 0000700 0 0 2 0 0 0 0 0 0 \0 0 0 1 0 3 4
> 0000720 2 0 0 0 0 \0 0 0 0 0 0 1 5 0 0 0
> 0000740 0 \0 001 5 6 7 0 3 1 7 1 0 0 0 \0 \0
> 0000760 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
>
> The length appears only at 0740 not 0600 and has a *leading* 001.
This is an array of offset+size pairs, and in your example the first
offset is zero.
Since it's an oldgnu header, it contains only 4 offsize+size pairs.
The 001 is the isextended flag. See tar/src/tar.h for the layout.
And see sparse.c for more details.
> Any best practices how to hex edit such large files?
For something like this I'd probably write a special-purpose C program.
- Re: [Bug-tar] new/old extract problems with 6GB sparse file, (continued)
Re: [Bug-tar] new/old extract problems with 6GB sparse file, Sergey Poznyakoff, 2006/06/19
Re: [Bug-tar] new/old extract problems with 6GB sparse file, Paul Eggert, 2006/06/19
Re: [Bug-tar] new/old extract problems with 6GB sparse file,
Paul Eggert <=