Re: mv --no-preserve-ownership

[Jim Meyering]

On Wed, Jul 1, 2015 at 9:15 AM, Pádraig Brady <address@hidden> wrote:
> On 01/07/15 16:58, sa wrote:
>> On 30.04.2015 22:27, sa wrote:
>>> On 30.04.2015 17:30, Pádraig Brady wrote:
>>>> On 30/04/15 13:02, sa wrote:
>>>>>
>>>>> it's still common today when you can copy files somewhere but subsequent
>>>>> chown() on them returns EACCES:
>>>>>
>>>>> NFS without strict uid/gid mapping,
>>>>> CIFS with broken Unix Extensions - nowaday NAS devices,
>>>>> less common filesystems like sshfs.
>>>
>>>> Maybe, but the `cp ... && rm` combo give more control
>>>> and isn't too awkward for this.  Also it doesn't have
>>>> a functional disadvantage of using extra space, as
>>>> generally this is an issue between separate file systems.
>>>
>>> I agree with these objections, but two orthogonal options
>>> of doing almost the same thing cause frustration.
>>> "Am I moving to remote share?" Then "is this one of those
>>> "bad" shares?" (and if you don't know, you must guess).
>>> Then, you type `cp ... && rm ...` or remember the name and options
>>> of custom script. Then, after starting it, you remember that
>>> SOURCE is on the same share and you must have used mv instead.
>>>
>>>
>>>> Also it has a functional advantage of being an atomic
>>>> operation, not deleting any files unless all were copied.
>>>
>>> I agree, but I'm happy with standard and expected mv behaviour,
>>> which is atomic move of each SOURCE argument.
>>>
>>> Search for "mv: failed to preserve ownership" (with quotes) gives
>>> an idea about diversity of failure cases.
>>>
>>> Please consider the trivial patch attached. It passes existing tests.
>>> I've tried to write a specific test, but couldn't find a safe way
>>> to force mv copy files instead of rename within test framework.
>>>
>>
>> What about this feature/patch?
>
> I can see the benefit though I'm not sure it's worth the new option.
> I'd like to hear from others before proceeding.
> Re the interface, it would be better to mimic
> the more general cp --no-preserve=ATTR_LIST option.
> Re the test, there are examples of loopback mounts in the tests
> which would create a separate file system, thus inducing a copy.

That change is small (good!) but does not provide a corresponding
--preserve... option: important for orthogonality, and for those who
alias or otherwise encapsulate mv --no-preserve... and then want to
override that.

Did you notice how the require_preserve_xattr and
require_preserve_context members are used? They do not inhibit the
attempt to preserve something, but rather control whether failure is
translated to an error. On the other hand, adding a new member in
copy.h would make this a bigger change, e.g., updating initializations
performed in each of mv, cp, install.

I'm on the fence: this is easy to work around (cp ... && rm ...), so
the bar for adding an option to do something similar is high.