With Samba 3.3.x, we moved to using the returned Windows permissions (as mapped from POSIX ACLs) to control all file access. This gets us closer to Windows behavior,but there's one catch. "Full Control" includes the ability to delete a file, but in POSIX the ability to delete a file belongs to the containing directory, not the file itself.
So when we return the Windows permissions for a file ACL with "rwx" set, by default we'd like to map to "Full Control" (see the default setting of the parameter acl map full control) but we must remove the DELETE_ACCESS flag from the mapping, as that is not a permission that is granted. Thus the ACL editor doesn't see "DELETE_ACCESS"in the returned ACE entry, and so doesn't believe it's "Full Control".
If we don't remove the DELETE_ACCESS bit, the client will open a file for delete, and successfully get a file handle back, but the delete will fail when the set file info (delete this file) call is made. Windows clients only check the error return on the open for
delete call, not the actual set file info that allows the delete - if you fail that call Windows explorer silently ignores the error, tells you you have deleted the file, but the file is still there and will reappear on the next directory refresh, thus confusing users.
So when we return the Windows permissions for a file ACL with "rwx" set, by default we'd like to map to "Full Control" (see the default setting of the parameter acl map full control) but we must remove the DELETE_ACCESS flag from the mapping, as that is not a permission that is granted. Thus the ACL editor doesn't see "DELETE_ACCESS"in the returned ACE entry, and so doesn't believe it's "Full Control".
If we don't remove the DELETE_ACCESS bit, the client will open a file for delete, and successfully get a file handle back, but the delete will fail when the set file info (delete this file) call is made. Windows clients only check the error return on the open for
delete call, not the actual set file info that allows the delete - if you fail that call Windows explorer silently ignores the error, tells you you have deleted the file, but the file is still there and will reappear on the next directory refresh, thus confusing users.
