Date: Tue, 1 Aug 2006 19:17:56 -0500 From: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> To: Garance A Drosehn <gad@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org Subject: Re: [PATCH] adding two new options to 'cp' Message-ID: <20060802001756.GB6671@megan.kiwi-computer.com> In-Reply-To: <p06230909c0f598682a82@[128.113.24.47]> References: <44CE199C.2020500@centtech.com> <17614.8289.134373.387558@bhuda.mired.org> <96b30c400607310847s1d2f845eo212b234d03f51e9a@mail.gmail.com> <17614.10982.499561.139268@bhuda.mired.org> <ealpn1$lan$1@sea.gmane.org> <20060801072611.GA717@turion.vk2pj.dyndns.org> <ean95a$e1u$1@sea.gmane.org> <p06230908c0f53813965d@[128.113.24.47]> <20060801171912.GC3413@megan.kiwi-computer.com> <p06230909c0f598682a82@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060802001756.GB6671>