Re: [PATCH] cifs: fix return code when failing to rename a file onto a directory

["Aurélien Aptel" <aaptel-IBi9RG/b67k@public.gmane.org>]

Pavel Shilovsky <piastryyy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
> What if the target is directory but the permissions are read-only?

I get the same resulsts on a local filesystem (xfs) and on a mounted
smb2 windows2016 share (both with and without the patch applied):

overwrite dir b with file a (with access to b)
=======================
rename("test/a", "test/b")              = -1 EISDIR (Is a directory)

overwrite dir b with file a (without access to b)
=======================
rename("test/a", "test/b")              = -1 EISDIR (Is a directory)

overwrite file b with file a (with access to b)
=======================
rename("test/a", "test/b")              = 0

overwrite file b with file a (without access to b)
=======================
rename("test/a", "test/b")              = 0

So.. I'm not sure what the xfstest test is doing.

The only difference between the local and remote fs is that for cifs you
can't delete test if you can't access test/b. (I am deleting "test"
between my tests).

That is on cifs:

  mkdir -p test/b
  chmod a-rw test/b
  rm -rf test

Will fail, but works on xfs. You you strace rm you will see:

  unlinkat(4, "b", AT_REMOVEDIR) = -1 EACCES (Permission denied)

I think this is due to the fundamental difference in how file removal
permission works in Windows vs POSIX. In POSIX you need +w on the parent
dir ("test") to be able to delete a file. On Windows there is a special
delete permission on the object itself. Not sure if this is "fixable".

Cheers,

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)