GNU bug report logs - #61050
mv: add support for --one-file-system

Previous Next

Full log

View this message in rfc822 format

From: Mike Frysinger <vapier <at> gentoo.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 61050 <at> debbugs.gnu.org
Subject: bug#61050: mv: add support for --one-file-system
Date: Wed, 25 Jan 2023 08:34:45 -0500

On 25 Jan 2023 01:07, Paul Eggert wrote:
> On 2023-01-24 17:20, Mike Frysinger wrote:
> > i'd like to require that the mv be
> > atomic when relocating a directory, and if it isn't, fallback to other
> > logic
> 
> Calling the new option "--one-file-system" sounds a bit wrong, as 
> --one-file-system is for programs like 'du' and 'cp' and causes them to 
> not cross a file system boundary when recursing - something that 'mv' 
> could also do (when it falls back on copying), but which is a different 
> thing than what you're asking for.
> 
> How about if we call the new option --no-copy instead? Something like 
> the attached incomplete patch, say. (It needs more documentation and 
> ideally a test case.)

either works for me, thanks

should there be a `--copy` flag to be able to undo `--no-copy` ?

> --- a/src/copy.c
> +++ b/src/copy.c
> @@ -2617,7 +2617,7 @@ copy_internal (char const *src_name, char const *dst_name,
>           where you'd replace '18' with the integer in parentheses that
>           was output from the perl one-liner above.
>           If necessary, of course, change '/tmp' to some other directory.  */
> -      if (rename_errno != EXDEV)
> +      if (rename_errno != EXDEV || x->no_copy)

personally i always argue against using negative variable names.  it's hard to
reason about, and reads like awkward english which requires multiple scans to
convince myself that it's correct.  but i rarely work on the coreutils code,
so feel free to ignore.
-mike

Previous Next

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