GNU bug report logs - #69532
mv's new -x option should be made orthogonal to -t/-T/default

Previous Next

Full log

View this message in rfc822 format

From: Petr Malat <oss <at> malat.biz>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 69532 <at> debbugs.gnu.org
Subject: bug#69532: mv's new -x option should be made orthogonal to -t/-T/default
Date: Tue, 5 Mar 2024 08:17:34 +0100

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.

But it doesn't behave like that when one uses -T, which is fine, because it's
documented.
 
> > > To fix this, 'mv -x' should respect the usual mv behavior with respect to
> > > directories. For example, when D is a directory 'mv -x A B C D' should act
> > > like 'mv A B C D' except that D's old entries should be renamed back to A B
> > > and C. And the -t and -T options should work with -x the same way they work
> > > when -x is not specified.
> > 
> > I do not think this is a good idea, because that operation is not
> > atomic.
> 
> There's nothing wrong with 'mv -x a b c d/' being nonatomic. "mv a b c d/"
> is not atomic either, and that's fine too.

The swap option description explicitly says it's atomic and the atomicity
was the only motivation for adding the new option.
 
> > Probably, the user wants to prepare a temporary directory
> > instead and then atomically swap it with the directory in use.
> 
> This usage was not at all obvious to me. If it's the intended use, I suggest
> inventing a new command, or adding -x to the 'rename' command instead.
> Pushing this flag onto 'mv', without making the flag reasonably orthogonal
> to mv's other options, would be a mistake because it would cause too much
> confusion.

The problem with a new command is that it's hard to find and rename
seems worst fitting than mv, because its main purpose is to replace
a pattern in a filename (e.g. change .JPG to .jpeg), so to "implement"
  mv A B
with rename one has to do
  rename A B A

Implementing atomic swap operation there doesn't seem logical to me,
I would never look for such a feature there. On the other hand when
I call mv A B, I'm generally interested in knowing if there is a time
frame, when no version of B exists.

> > Supporting swap for more than 2 files also brings a problem, when
> > the operation fails as then one doesn't know what has been swapped
> > and what not.
> 
> I don't see why not. The user can look at mv's diagnostics. It's the same as
> regular "mv a b c d/".

I don't find parsing diagnostics reliable and in general, it's something
I try to avoid in scripts. In a case I would do something like mv *.X d/,
and mv would fail, I would rather iterate over *.X than parse the output
to handle the error.
  Petr

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.