All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Pádraig Brady" <P@draigBrady.com>
To: Paul Eggert <eggert@cs.ucla.edu>
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: Sun, 17 Mar 2024 11:40:00 +0000	[thread overview]
Message-ID: <9d0cd94b-0601-44e2-9218-889b1bd35336@draigBrady.com> (raw)
In-Reply-To: <5308840a-9de4-33d0-2520-5f3addc9718c@draigBrady.com>

On 17/03/2024 11:32, Pádraig Brady wrote:
> On 17/03/2024 06:10, Paul Eggert wrote:
>> On 2024-03-05 06:16, Pádraig Brady wrote:
>>> I think I'll remove the as yet unreleased mv --swap from coreutils,
>>> given that
>>> util-linux is as widely available as coreutils on GNU/Linux platforms.
>>
>> Although removing that "mv --swap" implementation was a win, I don't
>> think we can simply delegate this to util-linux's exch command.
>> Exchanging files via a renameat-like call is not limited to the Linux
>> kernel; it's also possible on macOS via renameatx_np with RENAME_SWAP,
>> and there have been noises about adding similar things to other
>> operating systems.
>>
>> I just now added support for macOS renameatx_np to Gnulib, so coreutils
>> does not need to worry about the macOS details; it can simply use
>> renameatu with the Linux flags. See:
>>
>> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=af32ee824ee18255839f9812b8ed61aa5257a82b
>>
>> Even with Linux it's dicey. People may have older util-linux installed
>> and so lack the 'exch' utility; this is true for both Fedora 39 and
>> Ubuntu 23.10, the current releases. Ubuntu is also odd in that it
>> doesn't install all the util-linux utilities as part of the util-linux
>> package, so it's not clear what they will do with 'exch'.
>>
>> So I propose that we implement the idea in coreutils in a better way,
>> that interacts more nicely with -t, -T, etc. Also, I suggest using the
>> Linuxish name "--exchange" instead of the macOSish name "--swap", and
>> (for now at least) not giving the option a single-letter equivalent as I
>> expect it to be useful from scripts, not interactively.
>>
>> After looking at various ways to do it I came up with the attached
>> proposed patch. This should work on both GNU/Linux and macOS, if your OS
>> is recent enough and the file system supports atomic exchange.
> 
> The implementation looks good.
> 
> Re exch(1) on macos, I see util-linux is on homebrew,
> so it would be relatively easy to ifdef renameatx_np in util-linux also.
> 
> 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"
> 
> While the most flexible, it's also quite awkward to need
> `mv --exchange --no-copy --no-target-directory` for most uses.
> I.e. it's tempting to imply the --no-... options with --exchange,
> but I suppose since scripting is the primary use case for this
> flexibility trumps conciseness, so I'm ok with the verbosity I think.

Oh also in the texinfo I think it's important to mention that the swap
will "exchange all data and metadata". That's not obvious otherwise.
For example users may be wondering if only data was being exchanged
with the macos exchangedata(2) or equivalent.

cheers,
Pádraig

  reply	other threads:[~2024-03-17 11:40 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 [this message]
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
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=9d0cd94b-0601-44e2-9218-889b1bd35336@draigBrady.com \
    --to=p@draigbrady.com \
    --cc=69532@debbugs.gnu.org \
    --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.