Peter Jeremy PeterJeremy at
Thu Jul 22 02:16:36 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-ports mailing list