From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 00:09:13 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 540AE16A4DD for ; Wed, 2 Aug 2006 00:09:13 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF7AD43D49 for ; Wed, 2 Aug 2006 00:09:12 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id k72098IQ011178; Tue, 1 Aug 2006 20:09:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060801171912.GC3413@megan.kiwi-computer.com> References: <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> <20060801171912.GC3413@megan.kiwi-computer.com> Date: Tue, 1 Aug 2006 20:09:08 -0400 To: rick-freebsd@kiwi-computer.com From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) 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: Wed, 02 Aug 2006 00:09:13 -0000 At 12:19 PM -0500 8/1/06, Rick C. Petty wrote: >On Tue, Aug 01, 2006, Garance A Drosehn wrote: > > >> The point is not that you need an explicit switch, the >> point is that you have to add a lot of code to 'cp' for >> 'cp' to do the job correctly. > >Not really. See my example in a previous post. All you >need to do is perform an lseek(2) instead of a write(2) >if the block you read is all zero. I guess it depends on what the option will be described as doing. If you want an option which will "sparse-ify" any file, then yes that's easy to do. I had understood this option as a request to "copy all the existing holes", which is not the same thing. I.e., I thought we wanted `cp' to create the new file such that it would take up exactly the same number of disk blocks, and have the same number of holes (in exactly the same places) as the original file. I agree that "sparse-ify" should be easy to implement, and could be useful. I'm not fond of the idea, but I can see how people might want it. I do would not like it, because the user will have to know whether it is appropriate to use on a file-by-file basis. You can't just 'cp -rp' an entire directory, and feel confident that the "Right Thing(TM)" will happen for each file that is being copied. So, if I am copying directories, I'll still have to resort to some other tool to get the job done "Right(TM)". In my case, I want zeros on the disk in the destination wherever there were zeros on the disk in the source. In some situations, I don't want the number-of-blocks of a file to increase every time I change a X'00' to a X'01'. It would be nice for `cp' to do that too, but I expect *that* would add too much bloat to `cp'. Not only that, but it just sets us up for the next request for `cp' to do "perfectly-accurate copies" of files. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA