GNU bug report logs - #36831
enhance 'directory not empty' message

Previous Next

To reply to this bug, email your comments to 36831 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Alex Mantel <alexmantel93 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: enhance 'directory not empty' message
Date: Sun, 28 Jul 2019 20:58:59 +0200

[Message part 1 (text/plain, inline)]

i couldn't use move:

    $ mv thing/ ../things
    mv: cannot move 'thing' to '../things/things': Directory not empty

An i can not move it. i do not understand why. I have to google and find
at stackoverflow:

    Though its man page doesn't document it, mv will refuse to rename a
    directory to another directory if the target directory contains files.
    This is a good thing in your case because you turn out to want to
    merge the content of the source into the target, which mv will not do.

https://askubuntu.com/questions/269775/mv-directory-not-empty

Ah, the target directory does exist! Hmm... But i'd like the message to 
be like:

   $ mv thing/ ../things
   mv: cannot move 'thing' to '../things/things': Targetdirectory not empty

                                                  ^ this little thing here,
                                                    it explains everyting.

Change text from 'Directory not empty' to 'Targetdirectory not empty'.

[Message part 2 (text/html, inline)]

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Alex Mantel <alexmantel93 <at> gmail.com>
Cc: 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Mon, 29 Jul 2019 00:28:07 -0600

[Message part 1 (text/plain, inline)]

Hello,

On Sun, Jul 28, 2019 at 08:58:59PM +0200, Alex Mantel wrote:
[...] 
> Ah, the target directory does exist! Hmm... But i'd like the message to be
> like:
> 
>    $ mv thing/ ../things
>    mv: cannot move 'thing' to '../things/things': Targetdirectory not empty
> 
>                                                   ^ this little thing here,
>                                                     it explains everyting.
> 
> Change text from 'Directory not empty' to 'Targetdirectory not empty'.

Thanks for the report.

To clarify, the scenario is:

    $ mkdir A B B/A
    $ touch A/bar B/A/foo
    $ mv A B
    mv: cannot move 'A' to 'B/A': Directory not empty

And the reason (as you've found out) is that the target directory 'B/A'
is not empty (has the 'foo' file in it).
Had this been allowed, moving 'A' to 'B/A' would result in the 'foo'
file disappearing.

---

How is a user expecting to know this error is about that target
directory?

There is a bit of a trade-off here between user-friendliness (especially
for non-technical user) and more technical knowledge.
If we go one step 'lower' to the programming interface, almost all
sources mention this is about the 'target' directory not being empty:

POSIX's says:
https://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html
    [EEXIST] or [ENOTEMPTY]
        The link named by new is a directory that is not an empty directory.

Linux's rename(2) manual page says:
    ENOTEMPTY or EEXIST
        newpath is a nonempty directory, that is, contains entries
        other than "." and "..".

FreeBSD's rename(2) manual page says:
    [ENOTEMPTY]        The to argument is a directory and is not empty.

AIX rename(2) manual page says:
     ENOTEMPTY
       The ToPath parameter specifies an existing directory that is
       not empty.


So there is some merit in claiming this helpful piece of information is
lost when the error message is reported to the user.

---

In GNU coreutils this error message originates from 'copy.c' line 2480:
https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy.c#n2480

    error (0, rename_errno,
              _("cannot move %s to %s"),
              quoteaf_n (0, src_name), quoteaf_n (1, dst_name));

And herein lies the (technical) problem: The actual message "Directory
not empty" is not in the source code - it is a system error message
that corresponds to the value of 'rename_errno' variable
(ENOTEMPTY/EEXIST). It originates from GLibc (or another libc).

So there is no trivial way to change the error message in coreutils.

Attached a patch to add special handling for this error.

---

What do others think? If this is a desired improvement, I'll finish the
patch with news/tests/etc.


regards,
 - assaf

[0001-mv-improve-ENOTEMPTY-EEXIST-error-message.patch (text/plain, attachment)]

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

From: Jim Meyering <jim <at> meyering.net>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Mon, 29 Jul 2019 00:25:23 -0700

On Sun, Jul 28, 2019 at 11:29 PM Assaf Gordon <assafgordon <at> gmail.com> wrote:
...
> What do others think? If this is a desired improvement, I'll finish the
> patch with news/tests/etc.
...
> [PATCH] mv: improve ENOTEMPTY/EEXIST error message
>
> Suggested by Alex Mantel <alexmantel93 <at> gmail.com> in
> https://bugs.gnu.org/36831 .
>
>     $ mkdir A B B/A
>     $ touch A/bar B/A/foo
>
> Before:
>
>     $ mv A B
>     mv: cannot move 'A' to 'B/A': Directory not empty
>
> After:
>
>     $ mv A B
>     mv: cannot move 'A' to 'B/A': Target directory not empty
>
> * src/copy.c (copy_internal): Add special handling for ENOTEMPTY/EEXIST.
> TODO: NEWS, tests.

I like it. Thank you.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>, Alex Mantel <alexmantel93 <at> gmail.com>
Cc: 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Mon, 29 Jul 2019 18:50:46 -0500

[Message part 1 (text/plain, inline)]

On 7/29/19 1:28 AM, Assaf Gordon wrote:
> +      if (rename_errno == ENOTEMPTY || rename_errno == EEXIST)
> +        {
> +          error (0, 0, _("cannot move %s to %s: Target directory not empty"),
> +                 quoteaf_n (0, src_name), quoteaf_n (1, dst_name));

Although this is an improvement, it is not general enough, as other 
errno values are relevant only for the destination. Better would be to 
have a special case for errno values that matter only for the 
destination, and use the existing code for errno values where we don't 
know whether the problem is the source or the destination. Something 
like the attached, say.

[mv.diff (text/x-patch, attachment)]

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Wed, 31 Jul 2019 16:05:05 -0600

Hello Paul,

On Mon, Jul 29, 2019 at 06:50:46PM -0500, Paul Eggert wrote:
> On 7/29/19 1:28 AM, Assaf Gordon wrote:
> > +      if (rename_errno == ENOTEMPTY || rename_errno == EEXIST)
> > +        {
> > +          error (0, 0, _("cannot move %s to %s: Target directory not empty"),
> > +                 quoteaf_n (0, src_name), quoteaf_n (1, dst_name));
> 
> Although this is an improvement, it is not general enough, as other errno
> values are relevant only for the destination. Better would be to have a
> special case for errno values that matter only for the destination, and use
> the existing code for errno values where we don't know whether the problem
> is the source or the destination. Something like the attached, say.

> +            case EDQUOT: case EEXIST: case EISDIR: case ENOSPC: case ENOTEMPTY:
> +              error (0, rename_errno, "%s", quotearg_colon (dst_name));
> +              break;
> +

Thanks for the review.

At the risk of bikeshedding, I'd like to argue for the prior method.
While it is not general enough, I think it provides a clearer error message.

For example, with the more general implementation the errors would be:

  $ mv A B
  mv: B/A: Directory not empty

  $ mv A B
  mv: B/A: No space left on device

  $ mv A B
  mv: B/A: Quota exceeded

In the first case,
I think this error is potentially more confusing than
before: while it doesn't mention the source directory, it also doesn't
say "cannot move" - so it is only implied it is an error (an
inexperienced user might dismiss this as a warning).

Also, it could be that there will be a source directory named very similarly
to the destination directory, and from a quick glace it would not be easy to
understand what happened.

An explicit error explicitly saying "cannot move", and mention the source and
destination, and also "blames" the target directory seems the most
user-friendly and least ambiguous.

---

For the second and third cases,
"No space" and "Quota exceeded" seem to me to always relate to the
destination, and I don't think users get confused about those
(other opinions of course welcomed).

---

Your patch also added "EISDIR", for which rename(2) says:
 "newpath is an existing directory, but oldpath is not a directory."

But I don't think this error can happen with gnu mv.
If we try to move a file onto a directory, we get:

  $ mkdir C C/D ; touch D
  $ mv D C
  mv: cannot overwrite directory 'C/D' with non-directory

And this case is specifically handled in copy.c line 2131, before
calling rename(2)  (and also this is an example of a custom error
message instead of using stock libc messages).

---

Happy to hear your opinion,
 - assaf

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Assaf Gordon <assafgordon <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Thu, 1 Aug 2019 00:38:10 +0200

On 8/1/19 12:05 AM, Assaf Gordon wrote:
> Happy to hear your opinion,

+1
Including the full context about an error is essential:
- what did the tool try to do (at that point)?
- what was the problem? (e.g. ENOTEMPTY)
- where was the problem: src or dst?

Thanks & have a nice day,
Berny

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Wed, 31 Jul 2019 20:03:45 -0700

Assaf Gordon wrote:
> An explicit error explicitly saying "cannot move", and mention the source and
> destination, and also "blames" the target directory seems the most
> user-friendly and least ambiguous.

Sure, but that handles only the ENOTEMPTY/EEXIST case. How would you handle the 
EDQUOT, EISDIR, and ENOSPC cases? Will you invent a separate diagnostic for each 
case, or just treat them as in my proposed patch? I assume the latter, but 
either way I'd like to see a patch that handles these properly too. Also, please 
handle ETXTBUSY while you're at it (sorry, I missed that one).

> For the second and third cases,
> "No space" and "Quota exceeded" seem to me to always relate to the
> destination, and I don't think users get confused about those
> (other opinions of course welcomed).

What's obvious to experts like us is not always obvious to users. If users get 
confused by the current diagnostic for ENOTEMPTY/EEXIST, I don't see why they 
wouldn't also get confused for ETXTBUSY etc.

> Your patch also added "EISDIR", for which rename(2) says:
>  "newpath is an existing directory, but oldpath is not a directory."
> 
> But I don't think this error can happen with gnu mv.

It can, as a result of a race condition if some other process is mutating the 
file system while 'mv' is running. Admittedly unlikely, but we might as well 
improve this errno value while we're improving the others.

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

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Thu, 1 Aug 2019 10:32:09 +0200

Hi,

On Wed, Jul 31, 2019 at 04:05:05PM -0600, Assaf Gordon wrote:
> On Mon, Jul 29, 2019 at 06:50:46PM -0500, Paul Eggert wrote:
> > On 7/29/19 1:28 AM, Assaf Gordon wrote:
> > > +      if (rename_errno == ENOTEMPTY || rename_errno == EEXIST)
> > > +        {
> > > +          error (0, 0, _("cannot move %s to %s: Target directory not empty"),
> > > +                 quoteaf_n (0, src_name), quoteaf_n (1, dst_name));
> > 
> > Although this is an improvement, it is not general enough, as other errno
> > values are relevant only for the destination. Better would be to have a
> > special case for errno values that matter only for the destination, and use
> > the existing code for errno values where we don't know whether the problem
> > is the source or the destination. Something like the attached, say.
> 
> > +            case EDQUOT: case EEXIST: case EISDIR: case ENOSPC: case ENOTEMPTY:
> > +              error (0, rename_errno, "%s", quotearg_colon (dst_name));
> > +              break;
> > +
> 
> [...]
> An explicit error explicitly saying "cannot move", and mention the source and
> destination, and also "blames" the target directory seems the most
> user-friendly and least ambiguous.

I agree with this reasoning and prefer Assaf's error message improvement.

Thanks,
Erik
-- 
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
                        -- John Carmack

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Thu, 1 Aug 2019 04:15:00 -0600

[Message part 1 (text/plain, inline)]

Hello,

On Wed, Jul 31, 2019 at 08:03:45PM -0700, Paul Eggert wrote:
> Assaf Gordon wrote:
> > An explicit error explicitly saying "cannot move", and mention the source and
> > destination, and also "blames" the target directory seems the most
> > user-friendly and least ambiguous.
> 
> Sure, but that handles only the ENOTEMPTY/EEXIST case. How would you handle
> the EDQUOT, EISDIR, and ENOSPC cases? Will you invent a separate diagnostic
> for each case, or just treat them as in my proposed patch? I assume the
> latter, but either way I'd like to see a patch that handles these properly
> too. Also, please handle ETXTBUSY while you're at it (sorry, I missed that
> one).
> 
> > For the second and third cases,
> > "No space" and "Quota exceeded" seem to me to always relate to the
> > destination, and I don't think users get confused about those
> > (other opinions of course welcomed).
> 
> What's obvious to experts like us is not always obvious to users. If users
> get confused by the current diagnostic for ENOTEMPTY/EEXIST, I don't see why
> they wouldn't also get confused for ETXTBUSY etc.
> 
> > Your patch also added "EISDIR", for which rename(2) says:
> >  "newpath is an existing directory, but oldpath is not a directory."
> > 
> > But I don't think this error can happen with gnu mv.
> 
> It can, as a result of a race condition if some other process is mutating
> the file system while 'mv' is running. Admittedly unlikely, but we might as
> well improve this errno value while we're improving the others.

All good points.

Please see attached updated version.

It does add explicit error string for each error code, but I hope the
implementation is reasonable and easy to maintain and translate.

-assaf

[0001-mv-improve-error-messages-when-target-directory-is-a.patch (text/plain, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Thu, 1 Aug 2019 15:58:51 -0700

Thanks, that's better, but we're still missing some opportunities for improvement.

>     mv: cannot move 'A' to 'B/A': Target directory not empty

This should be "Destination" not "Target". (A target directory is something 
different; this is merely a destination directory.) Similar changes need to be 
made uniformly throughout the patch.


> +** Improvements
> +
> +  rm now prints clearer error messages when a failure relates to the

You meant "mv" not "rm".

Come to think of it, the same improvement should be made to ln, cp, install and 
shred. Basically, to any program that uses 'rename' or 'link' or similar 
syscalls, and which reports an error if the syscall fails.

> +static char*

Space before "*".

> +strerror_target (int e)

Change name to "strerror_dest" or something like that, to be consistent with the 
terminology "destination" rather than "target".

This function should return NULL instead of aborting when the errno value is 
inapplicable. That way, its callers need not hardcode which errno values it handles.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: enhance 'directory not empty' message
Date: Thu, 1 Aug 2019 21:47:54 -0600

[Message part 1 (text/plain, inline)]

On Thu, Aug 01, 2019 at 03:58:51PM -0700, Paul Eggert wrote:
> Thanks, that's better, but we're still missing some opportunities for improvement.
> 
> >     mv: cannot move 'A' to 'B/A': Target directory not empty
> 
> This should be "Destination" not "Target". 
[...] 
> You meant "mv" not "rm".
[...]
> > +static char*
> Space before "*".
[...]
> > +strerror_target (int e)
> Change name to "strerror_dest"
[...] 
> This function should return NULL instead of aborting when the errno value is
> inapplicable. That way, its callers need not hardcode which errno values it
> handles.

Thanks for the review and suggestions - attached an updated patch.

> Come to think of it, the same improvement should be made to ln, cp, install
> and shred. Basically, to any program that uses 'rename' or 'link' or similar
> syscalls, and which reports an error if the syscall fails.

OK, I will work on that next.

-assaf

[0001-mv-improve-error-messages-when-destination-directory.patch (text/plain, attachment)]

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>,
 36831 <at> debbugs.gnu.org
Subject: Enhance directory move.  (was Re: bug#36831: enhance 'directory not
 empty' message)
Date: Fri, 02 Aug 2019 02:41:31 -0700

On 2019/07/28 23:28, Assaf Gordon wrote:
>
>
>     $ mkdir A B B/A
>     $ touch A/bar B/A/foo
>     $ mv A B
>     mv: cannot move 'A' to 'B/A': Directory not empty
>
> And the reason (as you've found out) is that the target directory 'B/A'
> is not empty (has the 'foo' file in it).
> Had this been allowed, moving 'A' to 'B/A' would result in the 'foo'
> file disappearing.
>   
---
    Why must foo disappear?

    Microsoft Windows handles this situation by telling the user that
the target directory already exists and giving the option to *MERGE*
the directories.

    If you attempt to move a file into a directory that already contains
a file by the same name, it pops up another notice asking if you want
to replace the old with the new, keep it as it is (file won't be moved and
in this case, old directory would still exist with the unmoved files left
in it), or keep both with the new file getting a name variant (like
foo.exe -> foo_1.exe, keeping the extension the same so as to not mess
up the identity of the contents.

    But in all the cases, a file with a non-conflicting name wouldn't
disappear from the target.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>,
 36831 <at> debbugs.gnu.org
Subject: Re: Enhance directory move.  (was Re: bug#36831: enhance 'directory
 not empty' message)
Date: Fri, 2 Aug 2019 20:47:08 -0600

Hello,

On Fri, Aug 02, 2019 at 02:41:31AM -0700, L A Walsh wrote:
> On 2019/07/28 23:28, Assaf Gordon wrote:
> >
> >
> >     $ mkdir A B B/A
> >     $ touch A/bar B/A/foo
> >     $ mv A B
> >     mv: cannot move 'A' to 'B/A': Directory not empty
> >
> > And the reason (as you've found out) is that the target directory 'B/A'
> > is not empty (has the 'foo' file in it).
> > Had this been allowed, moving 'A' to 'B/A' would result in the 'foo'
> > file disappearing.
> >   
> ---
>     Why must foo disappear?
> 
>     Microsoft Windows handles this situation by telling the user that
> the target directory already exists and giving the option to *MERGE*
> the directories.
> 
>     If you attempt to move a file into a directory that already contains
> a file by the same name, it pops up another notice asking [...]

Certainly, GUI programs (and more 'feature-rich' programs than 'mv')
offer many "merging" options.

I'm sure Midnight-Commander, KDE/Doplhine, XFCE/Thunar, Gnome/Nautilus
and many other free software GUI file managers have some "merging"
capabilities.

But 'mv' is more basic and does not have this capability.
Partly that is because it adheres to the POSIX standards, which
mandates:
    "3. The mv utility shall perform actions equivalent to the
        rename() function [...]"
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html

Some rsync options (--remove-source-files) can mimick 'mv' with merging,
but then they are more like "copy+delete" than actual "rename/move".


Can new merging features be added to 'mv'? yes.
But it seems to me these would be better suited for 'higher level'
programs (e.g. a GUI file manager).

regards,
 - assaf

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Alex Mantel <alexmantel93 <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>,
 36831 <at> debbugs.gnu.org
Subject: Re: Enhance directory move.  (was Re: bug#36831: enhance 'directory
 not empty' message)
Date: Fri, 02 Aug 2019 20:56:15 -0700

On 2019/08/02 19:47, Assaf Gordon wrote:
> Can new merging features be added to 'mv'? yes.
> But it seems to me these would be better suited for 'higher level'
> programs (e.g. a GUI file manager).
---
	But neither the person who posted the original bug on this
nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on linux, so that wouldn't
be of any use.

If the command was named 'ren', then I'd expect it to be dummer,
but 'mv'/move seem like it should be able to move files from
one dir into another.

But you say posix wants it to perform as a rename?
I know, create a 're' command (or 'rn') for rename, and have
it do what 'mv' would do.  Maybe posix would realize it would
be better to have re/rn behave like rename, and 'mv' to
behave it was moving something.

So if I have:
mkdir A B
touch A/foo B/fee

So when I look at the system call on linux for rename:
       oldpath can specify a directory.  In this case, newpath must either not
       exist, or it must specify an empty directory.
        (complying with POSIX_C_SOURCE >= 200809L)

So move should give an error: Nope:

mv A B
> tree B
B
├── A
│   └── foo
└── fee

1 directory, 2 files

So mv is violating POSIX - it didn't do the rename, but moved
A under B and neither dir had to be empty.

Saying it has to follow POSIX when it doesn't appear to, seems
a bit contradictory?

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: alexmantel93 <at> gmail.com, 36831 <at> debbugs.gnu.org
Subject: Re: bug#36831: Enhance directory move. (was Re: bug#36831: enhance
 'directory not empty' message)
Date: Fri, 2 Aug 2019 23:39:41 -0600

Hello,

On 2019-08-02 9:56 p.m., L A Walsh wrote:
> On 2019/08/02 19:47, Assaf Gordon wrote:
>> Can new merging features be added to 'mv'? yes.
>> But it seems to me these would be better suited for 'higher level'
>> programs (e.g. a GUI file manager).
> ---
> 	But neither the person who posted the original bug on this
> nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on linux, so that wouldn't
> be of any use.

The original post was about the error *message*, asking to make it 
clearer. That is the topic of this thread (and the previous patch) -
so let's leave them at that.


I see you started a new thread ( https://bugs.gnu.org/36901 ),
so I'll reply there.

Previous Next

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