On 3/20/24 21:56, Paul Eggert wrote:
On 3/20/24 12:43, Bernhard Voelker wrote:
This stems from the fact that although mv(1) is a userland frontend
for renameat(2), the user interface is different:
while renameat(2) deals exactly with 2 operands, mv(1) has always
been able to work on more arguments.
Yes, that's mv's original sin, which we cannot realistically change now.
I wouldn't go that far that it was a sin. It's useful and people got
used to it without having to think about it.
I have the gut feeling that we didn't think through all cases,
and that some might be surprising, e.g.:
$ mkdir d; echo 1 > a; echo 2 > d/a
$ src/mv --exchange a a a a d/a
versus
$ src/mv --exchange a a a a d/a
I don't understand the word "versus" here, as the two examples look the
same to me.
sorry, I messed the example up.
$ echo 1 > a
$ mkdir d
$ echo 2 > d/a
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
2
$ src/mv -v --exchange a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
1
$ src/mv -v --exchange a a a a d
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
renamed 'a' -> 'd/a'
$ cat a
1
I remember some implementation where mv(1) really was just a rename(2),
which failed when crossing file systems. Was it some HP-UX or Solaris mv(1)?
mv(1) has learned to copy+delete over time, which is what people would
expect from a "move".
My point is that "exchange" is a different functionality.
It's well somehow belonging and related to what renameat(2) is doing in the kernel,
and therefore it comes in handy that we can simply call it with an additional flag.
Yet it's IMO a different operation. I bet there had been discussions whether
to create a new syscall, but apparently it was easier to put it with a flag
into an existing one. Fine for the kernel.
On userland OTOH, we have broader choice.
Karel did his choice in util-linux for exch(1), and coreutils could expose
the same functionality.
For other feature requests, we were much more reluctant in coreutils ... for
good reasons: feature bloat, maintainability, etc.
So I'm asking myself what is different this time?
- The feature already exists -> util-linux.
- Okay, we're using the same syscall, renameat(2) -> it's tempting.
- How large is the useful overlap with the existing code of mv(1)?
Not much: no traditional rename nor copy.
- How large is the useful overlap with the existing options/modes of mv(1)?
- exchange contradicts --backup,
- exchange is not useful together with options working with a regular
rename of copy, at least: --update, -Z, -n.
- not sure if exchange works well together with -f.
I'm currently only 20:80 for adding it to mv(1).
The functionality is cool, but do we need to press it into mv(1) with so many
incompatibilities just because it's requiring renameat(2) we already use?
Maybe to consider: One tool for one thing ... means another tool for another thing.
Again, I have the gut feeling that we've missed some cases to think about.
And once the feature would be in ...
Furthermore, why does exchange not work to exchange a regular with a directory file?
We've all learned that everything's a file, so it cannot be explained to users that
exchanging a regular file with a directory doesn't work.
Finally, the test cases are very sparse: no cases with different owners, different
directory permissions, different file types (if we know already f<->d doesn't work),
triggering races, etc.
I don't really want to object to add it, but I find it quite odd as of today.
Have a nice day,
Berny
