summaryrefslogtreecommitdiff
path: root/source4/selftest/knownfail
diff options
context:
space:
mode:
authorTim Prouty <tprouty@samba.org>2009-12-03 13:46:11 -0800
committerTim Prouty <tprouty@samba.org>2009-12-03 18:54:52 -0800
commit15e1c610273766a548a28b4d8731c6e9bad4496e (patch)
tree3a1fb3461555946e19b8a5b0f1af870acc3049c3 /source4/selftest/knownfail
parent8f7e5732ef3accd833906276f4a13891bac26726 (diff)
downloadsamba-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/selftest/knownfail')
0 files changed, 0 insertions, 0 deletions