On Thu, Mar 17, 2016 at 1:37 PM, <a...@korath.teln.shikadi.net> wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_FORTIFY_SOURCE=2
> -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
> -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
> -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
> -DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
> uname output: Linux korath.teln.shikadi.net 4.5.0-1-drm-intel-nightly #1
> SMP PREEMPT Sun Mar 13 10:42:04 AEST 2016 x86_64 GNU/Linux
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
>         Moving a directory to a non-existent path will rename the
> directory instead
>         of reporting that the destination directory does not exist.
>
> Repeat-By:
>         rmdir two 2> /dev/null
>         mkdir one
>         mv one two/
>
>         This should (and did in earlier versions) return an error, since
> the "two"
>         directory does not exist, so the "one" folder cannot be moved
> inside of it.
>         If the trailing slash was left off "two/", the command should (and
> does,
>         and always did) rename the folder.  However recently the command
> with the
>         trailing slash has started renaming the folder instead of
> returning an
>         error.
>
>         I often rely on the error result so that I don't have to check
> whether the
>         destination directory exists before performing the move operation,
> but now
>         the process will always succeed, silently becoming a rename
> operation
>         unpredictably.  I have already lost a handful of folders this way,
> only
>         realising later that they were renamed without warning when I did
> not
>         intend them to be renamed.
>
>
>
Thanks for the report, however bash is not involved, it is just passing the
argument to the "mv" command.
I can reproduce the behaviour with gnu mv, so maybe you are also using this
version, in which case you should
report to https://lists.gnu.org/mailman/listinfo/bug-coreutils

(I can reproduce with mv version 5.97 from 2006 so it's probably not that
new)

Reply via email to