Date: Tue, 20 Jul 2004 10:28:20 -0700 From: Julian Elischer <julian@elischer.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Andrey Chernov <ache@nagual.pp.ru> Subject: Re: NEW TAR Message-ID: <40FD5634.5040000@elischer.org> In-Reply-To: <20040720081051.GB3001@cirb503493.alcatel.com.au> References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <40FC9FC2.8050400@kientzle.com> <20040720081051.GB3001@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: >On Mon, 2004-Jul-19 21:29:54 -0700, Tim Kientzle wrote: > > >>I have some ideas about sparse file handling, >>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. >> >> > >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. > OR, given the right flags, note all blocks of zeros as if they were unallocated, and write them that way.. regardless of how it was in the original file. > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FD5634.5040000>