[PATCH] adding two new options to 'cp'

[Rick C. Petty]

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