On Wed, Jul 1, 2015 at 9:15 AM, Pádraig Brady <[email protected]> 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.
