Message-ID: <20250901170253.mv63jewqkdo5yqj7@pali>
Date: Mon, 1 Sep 2025 19:02:53 +0200
From: Pali Rohár <pali@...nel.org>
To: Stefan Metzmacher <metze@...ba.org>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
	ronnie sahlberg <ronniesahlberg@...il.com>,
	Ralph Böhme <slow@...ba.org>,
	linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/35] cifs: Fix SMB rmdir() and unlink() against Windows
 SMB servers

Hello!

On Monday 01 September 2025 09:55:45 Stefan Metzmacher wrote:
> 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.

Ok. So does it mean that the issue described here applies also for POSIX
SMB server?

If yes, then I would propose to first fix the problem with
Windows/non-POSIX SMB server and then with others. So it is not too big.

> > 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?

Currently (without this patch series) it is CIFSSMBRenameOpenFile()
function when called with NULL as 3rd argument.

Cleanup is done in PATCH 11/35, where are more details.

Originally the "Silly rename" is the term used by NFS client, when it
does rename instead of unlink when the path is in use.
I reused this term.


So for SMB this "silly rename" means:
- open path with DELETE access and get its handle
- rename path (via opened handle) to some unique (auto generated) name
- set delete pending state on the path (via opened handle)
- close handle

(plus some stuff around to remove READ_ONLY attr which may disallow to
open path with DELETE ACCESS)

So above silly rename means that the original path is not occupied
anymore (thanks to rename) and the original file / dir is removed after
all clients / users release handles (thanks to set delete pending).

It is clear now clear? Or do you need to explain some other steps?
Sometimes some parts are too obvious for me and I unintentionally omit
description for something which is important. And seems that this is
such case. So it is my mistake, I should have explain it better.

Powered by blists - more mailing lists