Re: [PATCH 00/35] cifs: Fix SMB rmdir() and unlink() against Windows SMB servers

[Stefan Metzmacher <metze@samba.org>]

Hi Pali,

> This patch series improves Linux rmdir() and unlink() syscalls called on
> SMB mounts exported from Windows SMB servers which do not implement
> POSIX semantics of the file and directory removal.
> 
> This patch series should have no impact and no function change when
> communicating with the POSIX SMB servers, as they should implement
> proper rmdir and unlink logic.

Please note that even servers implementing posix/unix extensions,
may also have windows clients connected operating on the same files/directories.
And in that case even posix clients will see the windows behaviour
of DELETE_PENDING for set disposition or on rename
NT_STATUS_ACCESS_DENIED or NT_STATUS_DIRECTORY_NOT_EMPTY.

> When issuing remove path command against non-POSIX / Windows SMB server,
> it let the directory entry which is being removed in the directory until
> all users / clients close all handles / references to that path.
> 
> POSIX requires from rmdir() and unlink() syscalls that after successful
> call, the requested path / directory entry is released and allows to
> create a new file or directory with that name. This is currently not
> working against non-POSIX / Windows SMB servers.
> 
> To workaround this problem fix and improve existing cifs silly rename
> code and extend it also to SMB2 and SMB3 dialects when communicating
> with Windows SMB servers. Silly rename is applied only when it is
> necessary (when some other client has opened file or directory).
> If no other client has the file / dir open then silly rename is not
> used.

If I 'git grep -i silly fs/smb/client' there's no hit, can you
please explain what code do you mean with silly rename?

Thanks!
metze