Date: Thu, 22 Jul 2004 09:30:39 +0200 (CEST) From: Harti Brandt <harti@freebsd.org> To: Andrey Chernov <ache@nagual.pp.ru> Cc: Tim Kientzle <tim@kientzle.com> Subject: Re: NEW TAR Message-ID: <20040722092624.A9549@beagle.kn.op.dlr.de> In-Reply-To: <20040722071929.GA13591@nagual.pp.ru> References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <40FC9FC2.8050400@kientzle.com> <20040722071929.GA13591@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 22 Jul 2004, Andrey Chernov wrote: AC>On Mon, Jul 19, 2004 at 09:29:54PM -0700, Tim Kientzle wrote: AC>> but they're not gtar-compatible. (The gtar AC>> approach has a number of drawbacks. The primary AC>> one being that on many systems it requires reading AC>> the entire file twice, once to find holes and again AC>> to actually archive the file. It is possible to AC>> do both in one pass if you store the sparse file AC>> data in a different fashion.) AC> AC>I can't imagine the case when 2 passes are needed. Even if you have normal AC>file in the archive and specify -S only when extracting (it should work as AC>expected), only 1 pass is needed. Just stop on first '\0' and count them AC>until they finished, then do lseek (real case will be a bit harder to AC>implement because of block boundaries). Imagine that you must store the hole data before the non-hole file content in the archieve. In that case you must read the input file to find the holes, write the hole data to the archive, rewind the input file and write all the non-hole data to the archive. If you do it the other way around (hole data at the end) you get a problem when extracting. The way I see would be to put the hole data in-line. This is also not without problems. AFAIK the tar format basically requires that you know how long something is before you can write it. harti
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040722092624.A9549>