NEW TAR

[Stefan Bethke]

Am 20.07.2004 um 10:10 schrieb Peter Jeremy:

> Actually, it's not possible to accurately determine the holes in a
> file by reading it - you can't differentiate between a hole and a
> allocated block of zeroes.  What you need is a (new) syscall that
> invokes a new VOP_... and returns a bitmap of allocated blocks.  This
> would be non-trival unfortunately.

This one point that has been made a number of times in the past, and 
one I don't understand:

There are no sparse files as far as the userland is concerned; it's an 
optimization that remains invisible, apart from space and/or 
performance savings.

For the extraction process, it should be sufficient to seek over any 
extended range of zeros. When packaging files that might have holes in 
them, it'll certainly be nice if there was a way to skip reading all 
those zeros in, but that's just an optimization.

The way you describe it (and others have before), it sounds like the 
holes were an attribute of the file that should be preserved by tar (or 
any other archiver); I believe it's not.  Preserving them in the way 
your post can be read is problematic: what if the 
block/allocation/cluster/fragment size of the extraction target differs 
from the source?  How far would you need to acertain compatible 
allocation semantics between both filesystems?

Since this has come up multiple times in the past, I feel I'm missing 
some important detail, and I'd appreciate if someone would enlighten 
me.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 170 346 0140