Re: getting creative with cp (was Re: cp -n diff)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Fri, 6 May 2011 15:45:47 -0400 (EDT)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > For example, does it help to think of cp as a two-part process: 1)
> > compare two directories or trees, 2) resolve differences between the
> > directories/trees by creating/destroying links or by making copies.
> 
> It's not quite where you seem to be going with that, but I do have a
> tool (I call it, imaginatively enough, "compare") that is specifically
> designed to compare two or more directory trees and list the
> differences.  It also has an option that says "the first one is a
> master copy, make the rest just like it".  It supports network-remote
> operation, either inetd-style or rsh-style, too; I routinely use it to
> update copies of things which I want to be identical on multiple
> machines (the first version was written back in the bad old SunOS days,
> to compare diskless root filesystems on the server).

What came to my mind was diff(1), which could be enhanced as well...

> Filesystem-level COW would be a very nice thing to have.  I would
> question whether it belongs in cp, though, or more precisely whether cp
> should be aware of it.  I would prefer to have the filesystem
> autodetect whenever a block is written that is identical in content to
> a block already present and share the data.  (Yes, what I'm talking
> about here borders on a content-addressed disk layer.)

This would probably be useful for trees or large files, however I
assume that heavy files fragmentation would result if it was more
generalized (i.e. if every zero block was shared, although in such a
specific case it would be in the cache, at least).  The other
potential issue would be reliability, as there would be less
redundancy; a lost block could mean serious damage...
-- 
Matt