summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy Allison <jra@samba.org>2005-11-14 07:08:05 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:47:11 -0500
commit95cc6bf4b39988a35ca55a891d5305a7c6ec88e7 (patch)
tree6dec16a8d7d8484436c035f322896434b1bef103
parentccaf005014edc8eb1397cd8fd5d78f2c70b3cfd3 (diff)
downloadsamba-95cc6bf4b39988a35ca55a891d5305a7c6ec88e7.tar.gz
samba-95cc6bf4b39988a35ca55a891d5305a7c6ec88e7.tar.bz2
samba-95cc6bf4b39988a35ca55a891d5305a7c6ec88e7.zip
Fix typos.
Jeremy. (This used to be commit baf8a510900f76f6b78e5e92c18f555187e50ea5)
-rw-r--r--docs/smbdotconf/protocol/aclcheckpermissions.xml11
1 files changed, 6 insertions, 5 deletions
diff --git a/docs/smbdotconf/protocol/aclcheckpermissions.xml b/docs/smbdotconf/protocol/aclcheckpermissions.xml
index 32ab30abc7..8619c51d3a 100644
--- a/docs/smbdotconf/protocol/aclcheckpermissions.xml
+++ b/docs/smbdotconf/protocol/aclcheckpermissions.xml
@@ -8,14 +8,14 @@
<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
+ actually attempting to delete the file or directory. As Windows clients 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
+ on "open for delete" request as we cannot restore such 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.
+ This is not perfect, as it's possible a user could have deleted a file without Samba being able to
+ check the permissions correctly, but it is close enough to Windows semantics for mostly correct
+ behaviour. Samba will correctly check POSIX ACL semantics in this case.
</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
@@ -24,6 +24,7 @@
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.
+ </para>
</description>
<value type="default">True</value>
</samba:parameter>