[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61050: mv: add support for --one-file-system
From: |
Mike Frysinger |
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