diff options
author | Tim Prouty <tprouty@samba.org> | 2009-12-03 13:46:11 -0800 |
---|---|---|
committer | Tim Prouty <tprouty@samba.org> | 2009-12-03 18:54:52 -0800 |
commit | 15e1c610273766a548a28b4d8731c6e9bad4496e (patch) | |
tree | 3a1fb3461555946e19b8a5b0f1af870acc3049c3 /source4/libgpo/ads_convenience.h | |
parent | 8f7e5732ef3accd833906276f4a13891bac26726 (diff) | |
download | samba-15e1c610273766a548a28b4d8731c6e9bad4496e.tar.gz samba-15e1c610273766a548a28b4d8731c6e9bad4496e.tar.bz2 samba-15e1c610273766a548a28b4d8731c6e9bad4496e.zip |
s4 torture: Add a new RAW-OPLOCK test: BATCH26
Try a rename with a wide-open share mode on an already open file
and the there is still share mode contention. For the reason why
see:
http://social.msdn.microsoft.com/Forums/en-US/os_fileservices/thread/3ca14dc9-da1f-4786-a8f7-a86e9903db0c
Msft's anser:
After further review, The reason for server to fail with sharing
violation is that the windows server that executes a path-based
rename request opens the file for DELETE access, but only with
FILE_SHARED_READ as ShareAccess . Therefore, the existing
open(frame 76), which has shared read/write/delete , is compatible
with the Windows servers access mode (DELETE), but Windows servers
open is not compatible with access mode in existing open.
Note that it is correct to state that the logic in Windows server
could have been written to allow shared read/write/delete in which
case it would succeed as you mention. The behavior here is
historical based on the existing implementation.
Diffstat (limited to 'source4/libgpo/ads_convenience.h')
0 files changed, 0 insertions, 0 deletions