Re: cp -u

[Bob Proulx]

Markku A. Mähönen wrote:
> 2008/6/14 Philip Rowlands <address@hidden>:
> > You might find rsync to be a better tool for this task. It's more robust
> > against partial-copy failures, and has the nice property that copied files
> > will all carry the same mtime, whereas cp -u will not attempt to replicate
> > timestamps (from a cursory check).
> 
> Ok, rsync might be better for this task (it seems to be quite a cpu hog
> though). But if you forget that, imho the 'cp -u' does not work as it
> should, so it is a bug.

I have not experienced any cpu hog problems with rsync.  Rsync
performs the task that the caller asks it to perform.  It will use
resources as appropriate to the task.  If all of the rsync
functionality were added to cp then cp would need to consume similar
resources.

The problem that people report is that when there are many clients
interacting with a single rsync server (such as for mirroring a
popular site) that the single server can be overwhelmed by the large
number of clients.  This acts as a distributed denial of service
attack.  But I dare say that you won't experience this when run as an
individual copy command.  I use rsync routinely on a P133MHz 32M ram
system and it doesn't hurt. :-)

'cp -u' is working as it should be with regards to the -u option.
However in the presence of errors if 'cp' is not reporting the error
then that would be a bug.

> I noticed that if, for some reason, the copy of a file is interrupted
> (and so the destination file is not the same size as the source) and

The online standards documentation for cp is here:

  http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html

Note this passage:

  EXIT STATUS

    The following exit values shall be returned:

     0 All files were copied successfully.
    >0 An error occurred.

  CONSEQUENCES OF ERRORS

    If cp is prematurely terminated by a signal or error, files or
    file hierarchies may be only partially copied and files and
    directories may have incorrect permissions or access and
    modification times.

Therefore the caller *must* check the exit code and handle errors
appropriately if it cares about them.  I suspect that your backup
script is not checking the exit code from cp and therefore not
handling the original interrupt condition.

Bob