tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Short circuit cp -l



In article <bc5ef420-ffdb-74ed-264a-b35c5aa0b3fc%NetBSD.org@localhost>,
D'Arcy Cain  <darcy%NetBSD.org@localhost> wrote:
>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.

Let's survey the other implementations (linux, etc.) and see what they
do, and decide. We should document this clearly as well as stating what
other implementations do, and why we decided to do what we decided so others
don't have to re-do this in the future.

christos



Home | Main Index | Thread Index | Old Index