On 25/10/2025 06:44, Philip Rowlands wrote:
Did this work?
mv -n AAA BBB
Not possible to tell in the simple case where BBB may or may not already exist.
We could check the result - has AAA gone? - but it's now a race condition. We
could turn on --verbose and try to parse the results, although --verbose output
probably isn't guaranteed stable.
The atomicity benefits of renameat2's RENAME_NOREPLACE are exposed with
--no-clobber but the resulting EEXIST code suppressed.
Would it be worthwhile having an option e.g. --no-clobber=fail to modify the
exit status when mv didn't perform the rename?
I haven't thought too hard about the semantics of moving a bunch of files to a
target directory, but we presumably have to deal with this today for -i / -b.
The use case is simply race-free renames. Imagine all the locking schemes you
could implement with mv(1)!
Note -n is best avoided due to platform differences.
Also -n should really exit with error status for consistency
with other "no-clobber" implementations in bash etc.
However we have the currently functionality of silently succeeding
in place too long now to change that (we did try to change
in v9.2 - v9.4 but there was push-back so we reverted in v9.5).
The good news though is that the --update=none=fail should do what you want.
See the online docs for details:
https://www.gnu.org/software/coreutils/mv
cheers,
Padraig
