Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Apr 1999 13:58:17 -0400
From:      Dennis Rockwell <dennis@bbn.com>
To:        naddy@mips.rhein-neckar.de (Christian Weisgerber)
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: Does tar do sparse files these days 
Message-ID:  <199904291758.NAA25146@po1.bbn.com>
In-Reply-To: Message from naddy@mips.rhein-neckar.de (Christian Weisgerber)  <7g7vdc$3e6$1@mips.rhein-neckar.de> .

next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Apr, Christian Weisgerber wrote:

> [ ... ] You *cannot* reliably recognize sparse
> files through the file API.  The state of the art, which you get when you
> invoke GNU tar with the -S option, is to compare stat.st_blocks with the
> file size. If there are fewer blocks than you'd expect from the size,
> there obviously must be holes somewhere, and you can now take guesses
> which large ranges of null bytes might be holes. This should work for
> most real world cases, but no way are you going to be able to exactly
> reproduce a file that freely intermixes holes with actual blocks of null
> bytes.

You would have to do run-length encoding of all strings of
nulls above some small threshhold, regardless of their
alignment, then always seek over these strings when
retrieving.  Since, as you say, the API doesn't reflect
these holes, manufacturing new holes isn't a problem, and
even saves some disk space.

I don't know if the file format would support this, and I
wouldn't expect something this CPU-expensive to be the
default behavior.

Dennis Rockwell                 dennis@bbn.com
GTE Internetworking
Powered by BBN                  +1-617-873-5745
Cambridge, MA                   +1-617-873-6091 (Fax)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904291758.NAA25146>