On 3/22/24 11:22, Karel Zak wrote:
> On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:>> 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
On 3/23/24 02:44, Paul Eggert wrote:
I installed the attached patches to do the above. (Basically, the
problem was that my earlier patches were too ambitious; these patches
scale things back to avoid some optimizations so that mv --exchange is
more like ordinary mv.)
The first patch simplifies
On 3/21/24 14:45, Bernhard Voelker wrote:
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
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.
There's another which is not
On Wed, Mar 20, 2024 at 11:53:05PM +0100, Bernhard Voelker wrote:
> 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
>
On 3/21/24 00:56, Paul Eggert wrote:
On 3/20/24 15:53, Bernhard Voelker wrote:
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.
There's another which is not consistent with/without --exchange:
$
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'
On 3/20/24 14:43, Bernhard Voelker wrote:
> On 3/17/24 07:10, Paul Eggert wrote:
> Now, extending "exchange" to more arguments is confusing and the
> use is not intuitive:
>mv -v --exchange a b c d
It's also pointless. An atomic exchange on more than 2 files ISN'T ATOMIC.
That's why I didn't
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
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:
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,
On 3/17/24 07:10, Paul Eggert wrote:
Although removing that "mv --swap" implementation was a win, I don't
think we can simply delegate this to util-linux's exch command.
I still have some headache adding this.
This stems from the fact that although mv(1) is a userland frontend
for
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
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,
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
When I knew RENAME_EXCHANGE, I thought we should extend mv command as
you did: adding --swap. However, after researching the past
challenges, I decided not to propose the feature to coreutils.
https://www.gnu.org/software/coreutils/rejected_requests.html
On Tue, Mar 05, 2024 at 02:16:05PM +, Pádraig Brady wrote:
> I think having the functionality in mv(1) is better than in rename(1),
> but since exch(1) is already released that's probably
> the best place for this functionality now.
>
> A separate exch command may be overkill for just this,
On 05/03/2024 04:10, Paul Eggert wrote:
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development
On Mon, Mar 04, 2024 at 04:24:27PM -0800, Paul Eggert wrote:
> On 3/4/24 15:37, Petr Malat wrote:
> > Why do you expect this?
>
> I expect it because mv has always treated destination directories that way.
> This has been true since the 1970s. We should not change this basic mode of
> operation.
On Mon, Mar 04, 2024 at 08:35:03PM +, P??draig Brady wrote:
> On 04/03/2024 15:47, P??draig Brady wrote:
> > On 04/03/2024 00:44, Paul Eggert wrote:
> > > Although I like the idea of exposing file swaps to the user, the first
> > > cut of 'mv -x' has significant problems.
> > >
> > > I expect
Hi Paul,
On Sun, Mar 03, 2024 at 04:44:52PM -0800, Paul Eggert wrote:
> Although I like the idea of exposing file swaps to the user, the first cut
> of 'mv -x' has significant problems.
>
> I expect 'mv -x A B' to act like 'mv A B' except the destination must exist
> and is renamed back to A.
On 3/4/24 18:43, Dominique Martinet wrote:
> Adding Rob to the loop because this impacts compatibility with
> toybox/maybe busybox implementations
> (Quoting in full for convenience, there's a few more mails in
> https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
> but we
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
(Quoting in full for convenience, there's a few more mails in
https://lists.nongnu.org/archive/html/bug-coreutils/2024-03/msg2.html
but we seem to be missing Petr's reply)
Pádraig Brady wrote
Paul Eggert wrote on Mon, Mar 04, 2024 at 08:10:35PM -0800:
> so there's little prior art there, and there's still plenty of time to fix
> its problems before exposing it to the world.
Yes, I just meant that everyone should agree, or there's little point in
implementing these for toybox/busybox,
On 3/4/24 12:35, Pádraig Brady wrote:
Another point worth mentioning before changing this,
is that changing would make the --swap operation non symmetric.
I.e. `mv -x a d` would be different to `mv -x d a` where d in a directory.
Yes, of course. It's just like mv without the -x. After you've
On 3/4/24 16:43, Dominique Martinet wrote:
Adding Rob to the loop because this impacts compatibility with
toybox/maybe busybox implementations
Busybox does not use RENAME_EXCHANGE, so this isn't a Busybox issue.
Toybox mv added -x to its development version yesterday:
On 3/4/24 15:37, Petr Malat wrote:
Why do you expect this?
I expect it because mv has always treated destination directories that
way. This has been true since the 1970s. We should not change this basic
mode of operation.
To fix this, 'mv -x' should respect the usual mv behavior with
On 3/4/24 15:16, Petr Malat wrote:
I prefer KISS principle and allowing
swapping just 2 paths.
In that case, the option should be added to the 'rename' command, not to
'mv'.
It is not KISS to add an option to 'mv' that makes it act completely
differently, such that most of mv's other
On 04/03/2024 15:47, Pádraig Brady wrote:
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to
On 04/03/2024 00:44, Paul Eggert wrote:
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B'
Although I like the idea of exposing file swaps to the user, the first
cut of 'mv -x' has significant problems.
I expect 'mv -x A B' to act like 'mv A B' except the destination must
exist and is renamed back to A. However, this is not true for 'mv -x A
B' when B is a directory; it renames B
30 matches
Mail list logo
