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

[David Young <dyoung%pobox.com@localhost>]

On Tue, May 03, 2011 at 10:08:12PM +0200, Marc Balmer wrote:
> I am sure as a creative developers community we can think of many other
> useful, non-POSIX additions to cp.

We do have a creative developer community, and I think that our
developers are open to the idea that we should strive for the most
useful, modern system that fits with the UNIX design philosophy.  UNIX
is more than forty years old, and it may sometimes require more serious
renovations than whittling away at command options.  Here are a handful
of possible renovations that this cp discussion has brought to mind:

A) De-composition / refactoring of tools: can cp, or can cp, ln, mv, and
   rm, divide into two or more useful parts?  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.

   In the first part of the process, are there useful ways to compare
   files than by pathname?  Content?

   Can we create one or more useful tools for each part of the
   process?

B) Speed it up: couldn't cp copy large directory trees much, much faster
   if it copied files concurrently instead of sequentially, thus giving
   the disk scheduler a lot more requests to chew on?  (See "Deceptive
   idleness.")

C) Speed it up some more: what if the kernel allowed for "lazy"
   copies to be made when the source & destination were on the same
   filesystem, and the filesystem supported it?  After a copy, source
   and destination would share data blocks, which would be copied on any
   subsequent write.  Yes, this would take a lot of kernel & filesystem
   hacking.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24