From: Bernhard Voelker <mail@bernhard-voelker.de>
To: "Paul Eggert" <eggert@cs.ucla.edu>, "Pádraig Brady" <P@draigBrady.com>
Cc: 69532@debbugs.gnu.org, util-linux <util-linux@vger.kernel.org>,
Dominique Martinet <asmadeus@codewreck.org>,
Petr Malat <oss@malat.biz>, Karel Zak <kzak@redhat.com>,
Rob Landley <rob@landley.net>
Subject: Re: bug#69532: mv's new -x option should be made orthogonal to -t/-T/default
Date: Wed, 20 Mar 2024 23:53:05 +0100 [thread overview]
Message-ID: <dcf073d9-a60b-429d-b9e2-40f6069e2641@bernhard-voelker.de> (raw)
In-Reply-To: <4356f3eb-544e-4ce9-b9ea-374cd01663d5@cs.ucla.edu>
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
next prev parent reply other threads:[~2024-03-20 22:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <10c814a7-cb68-4fb4-ad8d-f88f286fb0b1@cs.ucla.edu>
[not found] ` <58281f96-f9c6-4567-e3c9-c6a6cfa6ce27@draigBrady.com>
[not found] ` <ZeZqzB4-OzHYfFeQ@codewreck.org>
[not found] ` <5914e8b2-48ac-456b-9753-6a7bae7a9bbb@cs.ucla.edu>
2024-03-05 14:16 ` bug#69532: mv's new -x option should be made orthogonal to -t/-T/default Pádraig Brady
2024-03-05 20:41 ` Karel Zak
2024-03-05 22:13 ` Masatake YAMATO
2024-03-17 6:10 ` Paul Eggert
2024-03-17 11:32 ` Pádraig Brady
2024-03-17 11:40 ` Pádraig Brady
2024-03-20 22:10 ` Paul Eggert
2024-03-20 19:43 ` Bernhard Voelker
2024-03-20 20:56 ` Paul Eggert
2024-03-20 22:53 ` Bernhard Voelker [this message]
2024-03-20 23:56 ` Paul Eggert
2024-03-21 21:45 ` Bernhard Voelker
2024-03-23 1:44 ` Paul Eggert
2024-03-23 10:24 ` Bernhard Voelker
2024-03-22 10:22 ` Karel Zak
2024-03-23 10:24 ` Bernhard Voelker
2024-03-21 0:03 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dcf073d9-a60b-429d-b9e2-40f6069e2641@bernhard-voelker.de \
--to=mail@bernhard-voelker.de \
--cc=69532@debbugs.gnu.org \
--cc=P@draigBrady.com \
--cc=asmadeus@codewreck.org \
--cc=eggert@cs.ucla.edu \
--cc=kzak@redhat.com \
--cc=oss@malat.biz \
--cc=rob@landley.net \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.