GNU bug report logs - #9823
request for more correct error reporting of mv

Previous Next

Full log

Message #10 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: francky.leyn <at> telenet.be
Cc: Francky Leyn <Francky <at> Leyn.eu>, 9823 <at> debbugs.gnu.org
Subject: Re: bug#9823: request for more correct error reporting of mv
Date: Fri, 21 Oct 2011 06:59:22 -0600

tag 9823 moreinfo
thanks

On 10/21/2011 06:46 AM, francky.leyn <at> telenet.be wrote:
>
>
> Hello,
>
>
>
> if one uses mv to move a directory, and the target dir already
>
> exists, mv reports "Directory not empty".

Can you please show a shell session that sets up the necessary paths and 
the actual command you typed that resulted in this message?  A shell 
transcript will make it possible for us to repeat your actions and 
analyze them, much more so than a vague paraphrased English description.

For example, I tried this, and it didn't give an error:

$ rm -rf ?
$ mkdir a b
$ touch b/c
$ mv a b

but it did move a to become b/a.  Meanwhile, I can use a GNU extension 
to reproduce your error message:

$ rm -rf ?
$ mkdir a b
$ touch b/c
$ mv -T a b
mv: cannot move `a' to `b': Directory not empty

But to me, this gives me an expected error - directory b is not empty, 
therefore the syscall rename("a","b") is required to fail by POSIX, and 
POSIX states that the failure will be either EEXIST or ENOTEMPTY (Linux 
chose ENOTEMPTY) - so mv is faithfully reporting the strerror() value of 
the actual error encountered.  It's not possible to change the 
strerror() database, and printing a message not in the strerror() 
database can be confusing to developers that have come to expect 
specific output for specific errno values.

> I find this misleading. The message should also contain the
>
> message "target dir already exists" or something similar.

So it sounds like you'd prefer it if the message were for EEXIST instead 
of ENOTEMPTY?  Have you tried to take it up with the Linux kernel folks? 
 Or maybe coreutils could add a special case that if rename() fails 
with ENOTEMPTY and the conditions are right, then convert the errno to 
EEXIST before calling strerror().  But is it worth the minor 
pessimization (we do have precedence for some errno massaging, but it 
tends to need good justification)?  mv -T is seldom called in the first 
place, since it is not POSIX.

Or did you encounter a scenario with this error message without using 
GNU extensions?

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Previous Next

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