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.

0 files changed, 0 insertions, 0 deletions