coreutils
[Top][All Lists]
Advanced

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

Re: mv --no-preserve-ownership


From: Pádraig Brady
Subject: Re: mv --no-preserve-ownership
Date: Wed, 01 Jul 2015 17:15:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.

thanks,
Pádraig.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]