From owner-freebsd-current@FreeBSD.ORG Tue Jul 20 17:28:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37EFC16A4CE for ; Tue, 20 Jul 2004 17:28:30 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EEA843D66 for ; Tue, 20 Jul 2004 17:28:29 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i6KHSLUK239090; Tue, 20 Jul 2004 13:28:23 -0400 Message-ID: <40FD5634.5040000@elischer.org> Date: Tue, 20 Jul 2004 10:28:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Jeremy References: <40F963D8.6010201@freebsd.org> <20040719060730.GA87697@nagual.pp.ru> <40FC9FC2.8050400@kientzle.com> <20040720081051.GB3001@cirb503493.alcatel.com.au> In-Reply-To: <20040720081051.GB3001@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: Andrey Chernov Subject: Re: NEW TAR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 17:28:30 -0000 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. > > >