From: Paul Eggert <eggert@cs.ucla.edu>
To: "Pádraig Brady" <P@draigBrady.com>
Cc: 69532@debbugs.gnu.org, Petr Malat <oss@malat.biz>,
Rob Landley <rob@landley.net>,
util-linux <util-linux@vger.kernel.org>,
Dominique Martinet <asmadeus@codewreck.org>,
Karel Zak <kzak@redhat.com>
Subject: Re: bug#69532: mv's new -x option should be made orthogonal to -t/-T/default
Date: Wed, 20 Mar 2024 15:10:26 -0700 [thread overview]
Message-ID: <5db5740d-307f-4d6f-91a4-8451bb24e11a@cs.ucla.edu> (raw)
In-Reply-To: <5308840a-9de4-33d0-2520-5f3addc9718c@draigBrady.com>
On 3/17/24 04:32, Pádraig Brady wrote:
> I think the --no-copy situation is brittle, as scripts not using it now
> would be atomic, but then if we ever supported cross fs swaps
> it may become non atomic. I'd at least doc with a line in the --exchange
> description in usage() to say something like:
> "Use --no-copy to enforce atomic operation"
But --no-copy doesn't mean atomic operation; it simply means don't copy.
On systems that don't have an atomic exchange, we can emulate "mv
--exchange --no-copy a b" with three calls link("b", "b.tmp");
rename("a","b"); rename("b.tmp","a"). This wouldn't copy, but it
wouldn't be atomic.
Although atomicity is important, currently the coreutils documentation
doesn't cover it and the code doesn't always handle it well. For
example, if A and B are regular files "mv -b A B" briefly has a moment
when B stops existing. To my mind this is a bug: an existing destination
shouldn't stop existing merely because you're replacing it. At some
point this stuff should be documented better and this (and probably some
other) atomicity bugs fixed.
One thought I had while looking into this was that we could add an
--atomic option to mv and ln, such that the command fails if the
destination cannot be updated atomically. That would be a stronger
option than --no-copy. (In some cases we could support --atomic even for
'cp', no?)
Anyway, for now I installed the patch with some minor changes to the
documentation's --exchange section to try to document this tricky area
more clearly. Here's the revised doc section. It also incorporates your
later suggestion to mention both data and metadata.
----
@item --exchange
@opindex --exchange
Exchange source and destination instead of renaming source to destination.
Both files must exist; they need not be the same type.
This exchanges all data and metadata.
This option can be used to replace one directory with another.
When used this way, it should be combined with
@code{--no-target-directory} (@option{-T})
to avoid confusion about the destination location.
For example, you might use @samp{mv -T --exchange @var{d1} @var{d2}}
to exchange two directories @var{d1} and @var{d2}.
Exchanges are atomic if the source and destination are both in a
single file system that supports atomic exchange.
Non-atomic exchanges are not yet supported.
If the source and destination might not be on the same file system,
using @code{--no-copy} will prevent future versions of @command{mv}
from implementing the exchange by copying.
next prev parent reply other threads:[~2024-03-20 22:10 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 [this message]
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
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=5db5740d-307f-4d6f-91a4-8451bb24e11a@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=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.