Re: [Bug-tar] new/old extract problems with 6GB sparse file

[Paul Eggert]

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.