GNU bug report logs - #36901
mv: merge directories where target already exists

Previous Next

To reply to this bug, email your comments to 36901 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: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>
Subject: Enhance directory and file moves where target already exists
Date: Fri, 02 Aug 2019 20:34:36 -0700

Reposting this, since I realize that fixing the target-exists cases
with a helpful algorithm could change or eliminate many cases
where where now the user gets an error instead.



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 #8 received at 36901 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 36901 <at> debbugs.gnu.org
Subject: Re: bug#36901: Enhance directory and file moves where target already
 exists
Date: Fri, 2 Aug 2019 23:45:57 -0600

severity 36901 wishlist
retitle 36901 mv: merge directories where target already exists
stop

Hello,

(for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 )

For completeness, quoting your second message ( from https://bugs.gnu.org/36831#50 ):

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.
> 
> 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 #15 received at 36901 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 36901 <at> debbugs.gnu.org
Subject: Re: bug#36901: Enhance directory and file moves where target already
 exists
Date: Fri, 02 Aug 2019 22:47:18 -0700

It's not a wish list that 'mv' doesn't work as documented.


On 2019/08/02 22:45, Assaf Gordon wrote:
> severity 36901 wishlist
> retitle 36901 mv: merge directories where target already exists
> stop
> 
> Hello,
> 
> (for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 )
> 
> For completeness, quoting your second message ( from https://bugs.gnu.org/36831#50 ):
> 
> 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.
>>
>> 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 #18 received at 36901 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: L A Walsh <coreutils <at> tlinx.org>
Cc: 36901 <at> debbugs.gnu.org
Subject: Re: bug#36901: Enhance directory and file moves where target already
 exists
Date: Sat, 3 Aug 2019 00:10:08 -0600

Hello,

On Fri, Aug 02, 2019 at 10:47:18PM -0700, L A Walsh wrote:
> It's not a wish list that 'mv' doesn't work as documented.

The "wishlist" refers to the topic:
You are asking to add new funtionality to 'mv'.
That is a "wishlist" item.


(answering out of order:)

> > On 2019-08-02 9:56 p.m., L A Walsh wrote:
> >> But you say posix wants it to perform as a rename?
[...]
> >>
> >> 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?

I previously quoted one small part of the entire "mv" POSIX specification
(item #3, regarding using the 'rename(2)' function).

It would be wise to read the entire specification before making claims
about violating POSIX.
Specifically, at the top of the page:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
   SYNOPSIS
      mv [-if] source_file target_file
      mv [-if] source_file... target_dir
   DESCRIPTION
      [...]
      In the second synopsis form, mv shall move each file named by a
      source_file operand to a destination file in the existing directory
      named by the target_dir operand [...] This second form is assumed
      when the final operand names an existing directory

In this regard GNU 'mv' is compliant with POSIX.


> > 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).
> >> ---
> >> 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.

The Austin group (https://www.opengroup.org/austin/) who is in charge
of developing and maintaining the POSIX standard is the place
to go when wanting to change things in POSIX (or add new things).

You can write to them, suggest a modification,
and if they change the standard, GNU coreutils will surely follow.

As for renaming 'mv' or creating new 'rn' command -
part of POSIX is to codify existing behavior (that is - programs which
were in common use *before* POSIX).  It's not always logic, it's not always
ideal, but that's what has been in use for many years.

Based on mv's wiki page (https://en.wikipedia.org/wiki/Mv), 'mv' was
first introduced in 1971, 47 years ago.
With hindsight of nearly 5 decades it's easy to point to faults in a
program. If we were designing 'mv' today from scratch, I'm sure we would
improve many of its aspects.

But given that it is a long-standing program and its usage and quirks
are well established, I'm inclined to say it is highly unlikely
we will change mv's default behaviour or replace it with a different
name.

Adding new functionality (e.g. a new '--merge-directory' option)
is possible, and concrete patches are always welcomed.
However, given all the above, there is no guarentee that such new option
will be accepted.
I still think that such specific features are better suited for more
sophisticated programs (whether GUI or command line).

regards,
 - assaf

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 36901 <at> debbugs.gnu.org
Subject: Re: bug#36901: Enhance directory and file moves where target already
 exists
Date: Fri, 02 Aug 2019 23:21:43 -0700

On 2019/08/02 23:10, Assaf Gordon wrote:

>>>> 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 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?
> 
> I previously quoted one small part of the entire "mv" POSIX specification
> (item #3, regarding using the 'rename(2)' function).
> 
> It would be wise to read the entire specification before making claims
> about violating POSIX.
----
	One doesn't need to read all federal and state laws before 
making claims of law violation.


> Specifically, at the top of the page:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
>    SYNOPSIS
>       mv [-if] source_file target_file
>       mv [-if] source_file... target_dir
>    DESCRIPTION
>       [...]
>       In the second synopsis form, mv shall move each file named by a
>       source_file operand to a destination file in the existing directory
>       named by the target_dir operand [...] This second form is assumed
>       when the final operand names an existing directory
> 
> In this regard GNU 'mv' is compliant with POSIX.

But it isn't.  Note to mention -- which posix?  Different posix versions
are not the same.

It isn't 1 spec consistent spec, but changes overtime.  You quoted
a section saying it had to follow the behavior of rename, but it doesn't
do that:


And it doesn't follow the POSIX section quoted on the manpage.

>>>>         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)

mkdir A B
touch A/foo B/fee
mv A B

It B exists and is not empty.  Ergo, it is not following the 
requirement that the directory must be empty or not exist.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: L A Walsh <coreutils <at> tlinx.org>, Assaf Gordon <assafgordon <at> gmail.com>
Cc: 36901 <at> debbugs.gnu.org
Subject: Re: bug#36901: Enhance directory and file moves where target already
 exists
Date: Tue, 6 Aug 2019 21:14:24 +0200

On 8/3/19 8:21 AM, L A Walsh wrote:
> On 2019/08/02 23:10, Assaf Gordon wrote:
>> Specifically, at the top of the page:
>> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
>>    SYNOPSIS
>>       mv [-if] source_file target_file
>>       mv [-if] source_file... target_dir
>>    DESCRIPTION
>>       [...]
>>       In the second synopsis form, mv shall move each file named by a
>>       source_file operand to a destination file in the existing directory
>>       named by the target_dir operand [...] This second form is assumed
>>       when the final operand names an existing directory
>>
>> In this regard GNU 'mv' is compliant with POSIX.

[...]

> mkdir A B
> touch A/foo B/fee
> mv A B
> 
> It B exists and is not empty.  Ergo, it is not following the 
> requirement that the directory must be empty or not exist.

There no such condition in the POSIX citation (nor in the whole mv(1) spec)
about whether 'B' is empty or not.  The question is whether the target operant
is an existing directory (or a symlink which resolves to one).

Regards,
Berny

Previous Next

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