On 2018-07-18 02:11 AM, Robert Elz wrote: > You do understand though that you have changed the semantics? The > old way, cp -l would only link the files that could have been copied, now > it will happily link unreadable files. Also cp -il will no longer work, and > probably more.
I missed that. I don't see the first as being an issue. The second isn't an issue for me but it might be for others. However, since this is a non-standard option I suppose we can define it as we like. I am not sure what Linux does. The only other implementation is in OpenBSD and I know that they copied my code so perhaps they will also copy this change. A 10X speedup is nothing to ignore lightly. > With this change, I don't really know why the option needs to exist at > all, cp -l seems to be just a defective implementation of ln -f .. I'd be I think at the time I considered adding a -r option to ln instead but adding -l to cp was a lot less intrusive. The point, for me at least, of this option is to allow an exact, hard linked copy of a directory to be created for incremental backups so I always use it with "-r". The workflow is rsync to a backup directory, possibly from a remote machine and then make a hard link copy. The next day the rsync will copy over any changed files and the hard link copy will back them up incrementally. Something like "pax -rwl" but faster. Maybe I just need a stand-alone utility. > inclined to simply delete the -l option (or simply exec "ln" when the -l > option is given to cp, if there is some good reason for having a -l option). I certainly wouldn't want to exec something for every file. -- D'Arcy J.M. Cain <da...@netbsd.org> http://www.NetBSD.org/ IM:da...@vex.net
