coreutils
[Top][All Lists]
Advanced

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

Re: mv --no-preserve-ownership


From: sa
Subject: Re: mv --no-preserve-ownership
Date: Thu, 30 Apr 2015 22:27:02 +0300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

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.

--
sa

Attachment: mv-no-preserve-ownership.patch
Description: Text Data


reply via email to

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