GNU bug report logs - #21713
On CIFS, mv behaves as mv -f

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21713 in the body.
You can then email your comments to 21713 AT debbugs.gnu.org in the normal way.

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

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

From: Sam Kuper <sam.kuper <at> uclmail.net>
To: bug-coreutils <at> gnu.org
Subject: On CIFS, mv behaves as mv -f
Date: Mon, 19 Oct 2015 13:49:22 +0100

On a system where `df -T` shows the file system to be "cifs"
(presumably the Common Internet File System from Microsoft:
https://technet.microsoft.com/en-us/library/cc939973.aspx ), running
`mv` causes unexpected behaviour. Essentially, `mv` behaves as though
`mv -f` had been used.

Example, using GNU Coreutils 8.21 on Ubuntu 14.04.3 LTS:

$ which mv
/bin/mv
$ ls -l
total 0
$ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
-r-x------ 1 me me 4 1
-r-x------ 1 me me 4 2
$ echo bar > 2
-bash: 2: Permission denied
$ mv 1 2
$ ls -l | cut -d' ' -f 1-5,9
-r-x------ 1 me me 4 2

I would have expected the `mv 1 2` command to have prompted the user
before overwriting file 2. It would be helpful to the user if mv could
be improved so that it behaves as expected, even on a "cifs" file
system.

For comparison, running the same commands on a machine with an ext4
file system and a recent version of Coreutils yielded:

$ mv 1 2
mv: replace ‘2’, overriding mode 0444 (r--r--r--)?

as expected.

N.B. I first mentioned this issue at
http://unix.stackexchange.com/q/237123/6860 and am grateful for the
helpful feedback from the people who commented there, which helped me
identify the file system as the likely confounding factor.

Thank you for maintaining Coreutils!

Sam

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam Kuper <sam.kuper <at> uclmail.net>, 21713 <at> debbugs.gnu.org
Subject: Re: bug#21713: On CIFS, mv behaves as mv -f
Date: Mon, 19 Oct 2015 16:52:03 +0100

On 19/10/15 13:49, Sam Kuper wrote:
> On a system where `df -T` shows the file system to be "cifs"
> (presumably the Common Internet File System from Microsoft:
> https://technet.microsoft.com/en-us/library/cc939973.aspx ), running
> `mv` causes unexpected behaviour. Essentially, `mv` behaves as though
> `mv -f` had been used.
> 
> Example, using GNU Coreutils 8.21 on Ubuntu 14.04.3 LTS:
> 
> $ which mv
> /bin/mv
> $ ls -l
> total 0
> $ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
> -r-x------ 1 me me 4 1
> -r-x------ 1 me me 4 2
> $ echo bar > 2
> -bash: 2: Permission denied
> $ mv 1 2
> $ ls -l | cut -d' ' -f 1-5,9
> -r-x------ 1 me me 4 2
> 
> I would have expected the `mv 1 2` command to have prompted the user
> before overwriting file 2. It would be helpful to the user if mv could
> be improved so that it behaves as expected, even on a "cifs" file
> system.
> 
> For comparison, running the same commands on a machine with an ext4
> file system and a recent version of Coreutils yielded:
> 
> $ mv 1 2
> mv: replace ‘2’, overriding mode 0444 (r--r--r--)?
> 
> as expected.
> 
> N.B. I first mentioned this issue at
> http://unix.stackexchange.com/q/237123/6860 and am grateful for the
> helpful feedback from the people who commented there, which helped me
> identify the file system as the likely confounding factor.
> 
> Thank you for maintaining Coreutils!

I guess that's the write bits being ignored or mapped to another meaning on cifs?
I.E. access(..., W_OK) is returning OK (0) for you?
You can check this like: strace -e access mv 1 2

thanks,
Pádraig

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

From: Sam Kuper <sam.kuper <at> uclmail.net>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 21713 <at> debbugs.gnu.org
Subject: Re: bug#21713: On CIFS, mv behaves as mv -f
Date: Mon, 19 Oct 2015 18:30:26 +0100

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

On 19/10/2015, Pádraig Brady <P <at> draigbrady.com> wrote:
> On 19/10/15 13:49, Sam Kuper wrote:
>> On a system where `df -T` shows the file system to be "cifs"
>> (presumably the Common Internet File System from Microsoft:
>> https://technet.microsoft.com/en-us/library/cc939973.aspx ), running
>> `mv` causes unexpected behaviour. Essentially, `mv` behaves as though
>> `mv -f` had been used.
>>
>> Example, using GNU Coreutils 8.21 on Ubuntu 14.04.3 LTS:
>>
>> $ which mv
>> /bin/mv
>> $ ls -l
>> total 0
>> $ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
>> -r-x------ 1 me me 4 1
>> -r-x------ 1 me me 4 2
>> $ echo bar > 2
>> -bash: 2: Permission denied
>> $ mv 1 2
>> $ ls -l | cut -d' ' -f 1-5,9
>> -r-x------ 1 me me 4 2
>>
>> I would have expected the `mv 1 2` command to have prompted the user
>> before overwriting file 2. It would be helpful to the user if mv could
>> be improved so that it behaves as expected, even on a "cifs" file
>> system.
>>
>> For comparison, running the same commands on a machine with an ext4
>> file system and a recent version of Coreutils yielded:
>>
>> $ mv 1 2
>> mv: replace ‘2’, overriding mode 0444 (r--r--r--)?
>>
>> as expected.
>>
>> N.B. I first mentioned this issue at
>> http://unix.stackexchange.com/q/237123/6860 and am grateful for the
>> helpful feedback from the people who commented there, which helped me
>> identify the file system as the likely confounding factor.
>>
>> Thank you for maintaining Coreutils!
>
> I guess that's the write bits being ignored or mapped to another meaning on
> cifs?
> I.E. access(..., W_OK) is returning OK (0) for you?
> You can check this like: strace -e access mv 1 2

BEGIN TEST

$ ls -l
total 0
$ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
-r-x------ 1 me me 4 1
-r-x------ 1 me me 4 2
$ strace -e access mv 1 2
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("2", W_OK)                       = 0
+++ exited with 0 +++

END TEST

In case the test above hasn't reproduced clearly, due to line-wrapping
of my email, etc, I have attached it as a text file.

Thanks again,

Sam

[strace_mv_test.txt (text/plain, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam Kuper <sam.kuper <at> uclmail.net>
Cc: 21713 <at> debbugs.gnu.org
Subject: Re: bug#21713: On CIFS, mv behaves as mv -f
Date: Mon, 19 Oct 2015 18:37:34 +0100

tag 21713 notabug
close 21713
stop

On 19/10/15 18:30, Sam Kuper wrote:
> On 19/10/2015, Pádraig Brady <P <at> draigbrady.com> wrote:
>> On 19/10/15 13:49, Sam Kuper wrote:
>>> On a system where `df -T` shows the file system to be "cifs"
>>> (presumably the Common Internet File System from Microsoft:
>>> https://technet.microsoft.com/en-us/library/cc939973.aspx ), running
>>> `mv` causes unexpected behaviour. Essentially, `mv` behaves as though
>>> `mv -f` had been used.
>>>
>>> Example, using GNU Coreutils 8.21 on Ubuntu 14.04.3 LTS:
>>>
>>> $ which mv
>>> /bin/mv
>>> $ ls -l
>>> total 0
>>> $ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
>>> -r-x------ 1 me me 4 1
>>> -r-x------ 1 me me 4 2
>>> $ echo bar > 2
>>> -bash: 2: Permission denied
>>> $ mv 1 2
>>> $ ls -l | cut -d' ' -f 1-5,9
>>> -r-x------ 1 me me 4 2
>>>
>>> I would have expected the `mv 1 2` command to have prompted the user
>>> before overwriting file 2. It would be helpful to the user if mv could
>>> be improved so that it behaves as expected, even on a "cifs" file
>>> system.
>>>
>>> For comparison, running the same commands on a machine with an ext4
>>> file system and a recent version of Coreutils yielded:
>>>
>>> $ mv 1 2
>>> mv: replace ‘2’, overriding mode 0444 (r--r--r--)?
>>>
>>> as expected.
>>>
>>> N.B. I first mentioned this issue at
>>> http://unix.stackexchange.com/q/237123/6860 and am grateful for the
>>> helpful feedback from the people who commented there, which helped me
>>> identify the file system as the likely confounding factor.
>>>
>>> Thank you for maintaining Coreutils!
>>
>> I guess that's the write bits being ignored or mapped to another meaning on
>> cifs?
>> I.E. access(..., W_OK) is returning OK (0) for you?
>> You can check this like: strace -e access mv 1 2
> 
> BEGIN TEST
> 
> $ ls -l
> total 0
> $ echo foo > 1; chmod -w 1; cp 1 2; ls -l | cut -d' ' -f 1-5,9
> -r-x------ 1 me me 4 1
> -r-x------ 1 me me 4 2
> $ strace -e access mv 1 2

> access("2", W_OK)                       = 0
> +++ exited with 0 +++
> 
> END TEST

Right, so the file system is saying we can write to that file,
so not an issue with coreutils, rather a limitation of cifs,
or your cifs setup.

thanks,
Pádraig.

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

From: Sam Kuper <sam.kuper <at> uclmail.net>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 21713 <at> debbugs.gnu.org
Subject: Re: bug#21713: On CIFS, mv behaves as mv -f
Date: Mon, 19 Oct 2015 18:44:11 +0100

On 19/10/2015, Pádraig Brady <P <at> draigbrady.com> wrote:
> Right, so the file system is saying we can write to that file,
> so not an issue with coreutils, rather a limitation of cifs,
> or your cifs setup.

Understood.

My guess is that it is a limitation of CIFS. Unfortunately, I am not
the sysadmin for the system on which I encountered this issue, so
there is no easy way for me to investigate further (e.g. by altering
the CIFS configuration to see if the issue persists).

Thank you again for your help.

Sam

Previous Next

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