NEW TAR
Peter Jeremy
PeterJeremy at optushome.com.au
Thu Jul 22 02:16:35 PDT 2004
On Thu, 2004-Jul-22 11:19:29 +0400, Andrey Chernov wrote:
>On Mon, Jul 19, 2004 at 09:29:54PM -0700, Tim Kientzle wrote:
>> but they're not gtar-compatible. (The gtar
>> approach has a number of drawbacks. The primary
>> one being that on many systems it requires reading
>> the entire file twice, once to find holes and again
>> to actually archive the file. It is possible to
>> do both in one pass if you store the sparse file
>> data in a different fashion.)
>
>I can't imagine the case when 2 passes are needed. Even if you have normal
>file in the archive and specify -S only when extracting (it should work as
>expected), only 1 pass is needed. Just stop on first '\0' and count them
>until they finished, then do lseek (real case will be a bit harder to
>implement because of block boundaries).
I thought gnutar implemented sparse files by writing a bitmap of used
blocks vs holes followed by the actual data. This needs 1 pass to
calculate the bitmap and a second pass to write the data. You probably
don't want to unnecessarily convert holes to data in your archive.
Some Un*x systems generate a core dump by writing the process memory
map to a file - holes and all - giving you a sparse file that appears
to be several GB in size. Older dbm variants also tended to leave
large holes in the .pag file from memory.
--
Peter Jeremy
More information about the freebsd-current
mailing list