From: Paul Eggert <eggert@cs.ucla.edu>
To: "Bernhard Voelker" <mail@bernhard-voelker.de>,
"Pádraig Brady" <P@draigBrady.com>
Cc: Petr Malat <oss@malat.biz>,
util-linux <util-linux@vger.kernel.org>,
Dominique Martinet <asmadeus@codewreck.org>,
69532@debbugs.gnu.org, 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 16:56:32 -0700 [thread overview]
Message-ID: <e1269c19-c2b9-45ac-b683-47a473326662@cs.ucla.edu> (raw)
In-Reply-To: <dcf073d9-a60b-429d-b9e2-40f6069e2641@bernhard-voelker.de>
On 3/20/24 15:53, Bernhard Voelker wrote:
> $ 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
Yes, that's the expected behavior for this contrived case. Just as one
would get odd behavior if one did the same thing without --exchange.
> 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)?
I doubt it. Even 7th Edition 'mv' (1979) fell back on 'cp' when the link
syscall failed (this was before 'rename' existed).
> My point is that "exchange" is a different functionality.
Yes, but it's closely related. Arguably --backup is also a different
functionality too (and arguably --exchange is simply an alternative
backup scheme!) but 'mv' has --backup.
> - How large is the useful overlap with the existing code of mv(1)?
> Not much: no traditional rename nor copy.
I don't follow this point. The code change was fairly small, which
indicates there was a lot of overlap with existing functionality.
> - How large is the useful overlap with the existing options/modes of mv(1)?
> - exchange contradicts --backup,
That could be fixed for regular files, if there's a need, by backing up
the destination via 'link' before exchanging. For directories it's
admittedly a problem, but that's also the case for plain 'mv' (or for
'cp' or 'ln', for that matter) so there's not much new here.
> - exchange is not useful together with options working with a regular
> rename of copy, at least: --update, -Z, -n.
It should work with --update and -Z. -n of course is logically
incompatible, but this not the only set of logically incompatible
options (e.g., -t vs -T).
> - not sure if exchange works well together with -f.
What problems do you see there?
> why does exchange not work to exchange a regular with a
> directory file?
It works. I don't see a problem there.
$ touch a
$ mkdir d
$ ./mv -T --exchange a d
$ ls -ld a d
drwxr-xr-x. 2 eggert eggert 4096 Mar 20 16:52 a
-rw-r--r--. 1 eggert eggert 0 Mar 20 16:52 d
> Finally, the test cases are very sparse:
Feel free to add some. :-)
next prev parent reply other threads:[~2024-03-20 23:56 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
2024-03-20 23:56 ` Paul Eggert [this message]
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=e1269c19-c2b9-45ac-b683-47a473326662@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=69532@debbugs.gnu.org \
--cc=P@draigBrady.com \
--cc=asmadeus@codewreck.org \
--cc=kzak@redhat.com \
--cc=mail@bernhard-voelker.de \
--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.