From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 2 00:17:58 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 5762516A4DE for ; Wed, 2 Aug 2006 00:17:58 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 69C9343D49 for ; Wed, 2 Aug 2006 00:17:57 +0000 (GMT) (envelope-from rick@kiwi-computer.com) Received: (qmail 7187 invoked by uid 2001); 2 Aug 2006 00:17:56 -0000 Date: Tue, 1 Aug 2006 19:17:56 -0500 From: "Rick C. Petty" To: Garance A Drosehn Message-ID: <20060802001756.GB6671@megan.kiwi-computer.com> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i 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 Reply-To: rick-freebsd@kiwi-computer.com 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:17:58 -0000 On Tue, Aug 01, 2006 at 08:09:08PM -0400, Garance A Drosehn wrote: > > 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. Which it currently doesn't, without any sparse option. A copied file will always be larger than the original (in terms of disk blocks) if the original had any sparseness. > 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)". I don't see why not. If you're mixing sparse and non-sparse files in a tree and wish to duplicate this precisely, you need dump/restore.. oh, and those only work for UFS filesystems. Whatever the Right Thing is, you should have a good idea whether you wish to sparsify or anti-sparsify the files beneath (current cp does the anti-sparsify). If you're doing a directory copy and cannot choose which is the Right Thing for everything within that directory, then cp(1) certainly is not your choice. > In my case, I want zeros on the disk in the destination > wherever there were zeros on the disk in the source. This may be true with cp(1) as it is now, but certainly the converse is not guaranteed to be true. > 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'. Whereas the opposite situation is preferrable? Hmm, I'm using Y bytes of storage within this directory tree, let's move that to another partition. I'll make that partition at least Y bytes big. Recursive copy-- whoa! Out of space? Darn. -- Rick C. Petty