GNU bug report logs -
#21713
On CIFS, mv behaves as mv -f
Previous Next
Reported by: Sam Kuper <sam.kuper <at> uclmail.net>
Date: Mon, 19 Oct 2015 15:36:02 UTC
Severity: normal
Tags: notabug
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 6 years and 269 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.