From 634019f0a92ce24e5e070c4adc07ea4397981694 Mon Sep 17 00:00:00 2001
From: Jeremy Allison <jra@samba.org>
Date: Mon, 14 Nov 2005 07:03:42 +0000
Subject: [PATCH] Document "acl check permissions" for 3.0.21. Jeremy.

---
 docs/smbdotconf/protocol/aclcheckpermissions.xml | 29 ++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 docs/smbdotconf/protocol/aclcheckpermissions.xml

diff --git a/docs/smbdotconf/protocol/aclcheckpermissions.xml b/docs/smbdotconf/protocol/aclcheckpermissions.xml
new file mode 100644
index 00000000000..32ab30abc7b
--- /dev/null
+++ b/docs/smbdotconf/protocol/aclcheckpermissions.xml
@@ -0,0 +1,29 @@
+<samba:parameter name="acl check permissions"
+                 context="S"
+		 type="boolean"
+                 advanced="1" wizard="1"
+                 xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
+<description>
+    <para>This boolean parameter controls what <citerefentry><refentrytitle>smbd</refentrytitle> 
+    <manvolnum>8</manvolnum></citerefentry>does on receiving a protocol request of "open for delete"
+    from a Windows client. If a Windows client doesn't have permissions to delete a file then they
+    expect this to be denied at open time. POSIX systems normally only detect restrictions on delete by
+    actually attempting to delete the file or directory. As Windows client can (and do) "back out" a
+    delete request by unsetting the "delete on close" bit Samba cannot delete the file immediately
+    on "open for delete" request as we cannot restore a deleted file. With this parameter set to
+    true (the default) then smbd checks the file system permissions directly on "open for delete" and denies the
+    request without actually deleting the file if the file system permissions would seem to deny it.
+    This is not perfect, as it's possible a user can delete a file without Samba being able to
+    check the permissions, but it is close enough to Windows semantics for mostly correct
+    behaviour.
+    </para>
+    <para>If this parameter is set to "false" Samba doesn't check permissions on "open for delete"
+    and allows the open. If the user doesn't have permission to delete the file this will only be
+    discovered at close time, which is too late for the Windows user tools to display an error message
+    to the user. The symptom of this is files that appear to have been deleted "magically" re-appearing
+    on a Windows explorer refersh. This is an extremely advanced protocol option which should not
+    need to be changed. This parameter was introduced in its final form in 3.0.21, an earlier version
+    with slightly different semantics was introduced in 3.0.20. This version is not documented here.
+</description>
+<value type="default">True</value>
+</samba:parameter>
-- 
2.11.4.GIT