Joerg Delker <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
