Re: mv to a non-existent path now renames instead of failing

[Pierre Gaston]

On Thu, Mar 17, 2016 at 1:37 PM, <adam@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)