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)