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 0140Received on Tue Jul 20 2004 - 19:14:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:02 UTC