Re: mv --no-preserve-ownership

[sa]

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

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