From 8daa83a594a2e98f39d764422bfbdbc62c9efd44 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Fri, 19 Apr 2024 19:20:00 +0200 Subject: Adding upstream version 2:4.20.0+dfsg. Signed-off-by: Daniel Baumann --- docs-xml/smbdotconf/tuning/strictrename.xml | 34 +++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 docs-xml/smbdotconf/tuning/strictrename.xml (limited to 'docs-xml/smbdotconf/tuning/strictrename.xml') diff --git a/docs-xml/smbdotconf/tuning/strictrename.xml b/docs-xml/smbdotconf/tuning/strictrename.xml new file mode 100644 index 0000000..91572f2 --- /dev/null +++ b/docs-xml/smbdotconf/tuning/strictrename.xml @@ -0,0 +1,34 @@ + + + By default a Windows SMB server prevents directory + renames when there are open file or directory handles below + it in the filesystem hierarchy. Historically Samba has always + allowed this as POSIX filesystem semantics require it. + + This boolean parameter allows Samba to match the Windows + behavior. Setting this to "yes" is a very expensive change, + as it forces Samba to travers the entire open file handle + database on every directory rename request. In a clustered + Samba system the cost is even greater than the non-clustered + case. + + When set to "no" smbd only checks the local process + the client is attached to for open files below a directory + being renamed, instead of checking for open files across all + smbd processes. + + Because of the expense in fully searching the database, + the default is "no", and it is recommended to be left that way + unless a specific Windows application requires it to be changed. + + If the client has requested UNIX extensions (POSIX + pathnames) then renames are always allowed and this parameter + has no effect. + + + +no + -- cgit v1.2.3