From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 1 17:27:45 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2820016A4DF for ; Tue, 1 Aug 2006 17:27:45 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F01E043D6B for ; Tue, 1 Aug 2006 17:27:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k71HRbpa036354; Tue, 1 Aug 2006 12:27:37 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CF8F1A.5090506@centtech.com> Date: Tue, 01 Aug 2006 12:27:54 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <200607271150.k6RBoM9p031745@lurza.secnetix.de> <44C8FB65.9020102@FreeBSD.org> <44CE03D2.2050803@centtech.com> <17614.4005.407223.621637@bhuda.mired.org> <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <20060801171150.GB3413@megan.kiwi-computer.com> In-Reply-To: <20060801171150.GB3413@megan.kiwi-computer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1630/Tue Aug 1 10:38:56 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:27:45 -0000 On 08/01/06 12:11, Rick C. Petty wrote: > On Tue, Aug 01, 2006 at 05:26:11PM +1000, Peter Jeremy wrote: >> On Mon, 2006-Jul-31 22:42:49 +0200, Ivan Voras wrote: >>> I agree with this, and while you're in there, can you add -s to copy >>> sparse files (via the usual "if the buffer is all nulls, seek beyond eof >>> instead of writing" trick)? >> Note that it isn's possible to accurately distinguish between a block >> of NULs and a hole in the file through the filesystem. The only way >> to accurately copy a sparse file is with dump/restore. > > Sure it is-- in a number of ways. The most useful way is to do something > of the sort: > > int sd, dd; // assume these are set to source & dest descriptors > unsigned char* zeros; > unsigned char* buffer; > struct stat st; > size_t bytes, offset; > > fstat(sd, &st); > zeros = malloc(st.st_blksize); > bzero(zeros, st.st_blksize); > > for (offset = 0; offset < st.st_size; offset += bytes) > { > bytes = st.st_blksize; > if (offset + bytes > st.st_size) > bytes = st.st_size - offset; > read(sd, buffer, bytes); > if (0 == memcmp(buffer, zeros, bytes)) > lseek(dd, bytes, SEEK_CUR); > else > write(sd, buffer, bytes); > } > > Obviously, I didn't add the error checking/handling, but AFAIK this is > essentially what the -S option to gnu's tar does. In this example, you > may not mimic the allocated blocks of a sparse file, but you would > optimize the copy to use as few filesystem blocks as possible. Wouldn't this be incorrect for files that are really full of zeros? It would turn them in to sparse files when they shouldn't be, correct? Is that what happens with other tools? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------