bug#21713: On CIFS, mv behaves as mv -f

[Sam Kuper]

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

bug#21713: On CIFS, mv behaves as mv -f

[Pádraig Brady]

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

bug#21713: On CIFS, mv behaves as mv -f

[Sam Kuper]

On 19/10/2015, Pádraig Brady  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
$ 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 +++

bug#21713: On CIFS, mv behaves as mv -f

[Pádraig Brady]

tag 21713 notabug
close 21713
stop

On 19/10/15 18:30, Sam Kuper wrote:
> On 19/10/2015, Pádraig Brady  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.

bug#21713: On CIFS, mv behaves as mv -f

[Sam Kuper]

On 19/10/2015, Pádraig Brady  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