Markku A. Mähönen wrote: > 2008/6/14 Philip Rowlands <[EMAIL PROTECTED]>: > > 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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
