[PATCH]: Fix a delete on close divergence from windows and the associated torture test

[Tim Prouty]

Hi Jeremy,

While working on the OneFS SMB_VFS_CREATE_FILE implementation, I  
discovered what looks like a bug in the delete on close semantics in  
master, and probably prior releases.  To get you up to speed, I've  
been spending time analyzing your addition of the  
SHARE_MODE_ALLOW_INITIAL_DELETE_ON_CLOSE flag (commit:  
dbfd6bf8c8cc9945c4ba7e22ac44b1f33f9c7ce6).

The issue that got me started on this is that smbtorture4 BASE-DELETE  
is failing for me when I run it against win2k3, win2k8, and winXPsp2.   
They all fail on deltest17.  Winxp also fails two other tests which I  
believe is due to an implementation difference between the two, and I  
have added comments in the associated tests in the patches linked to  
below.

deltest17 does the following:

1. open file -> file is created
2. closes file
3. open file with DOC -> fnum1
4. check that DOC is not reported as being set from fnum1
5. opens file again Read Only -> fnum2
6. check that DOC is not reported as being set from either file handle
7. close fnum1 (the file handle that requested DOC to be set)
8. check if DOC is reported as being set from fnum2
* This is where windows and samba begin to diverge.  Windows reports  
that the DOC bit is set, while samba reports that it is not set.
9. close fnum2 (the last remaining open handle for the file)
10. See if the file has been deleted.
* On samba the file still exists.  On windows the file was deleted.


The way open_file_ntcreate is written now, if an open has the DOC bit  
set on the wire, DOC (fsp->initial_delete_on_close) is not set unless:
a. the open creates the file, or
b. there is an open file handle with a share_entry in the struct lck  
that has the SHARE_MODE_ALLOW_INITIAL_DELETE_ON_CLOSE bit set (let's  
call it SM_AIDOC).

My understanding of SM_AIDOC is that it was added to differentiate  
between DOC being set on an open that creates a file vs an open that  
opens an existing.  As described in step 8/10 above, it appears that  
windows does not make this differentiation.  Have you seen evidence to  
support that this isn't the case?

To resolve this issue I have written two patches:
http://git.samba.org/?p=tprouty/samba.git;a=shortlog;h=refs/heads/delete_on_close_bug 
.

The first patch is a simple proof of concept change that is sufficient  
to fix the bug.   It removes the differentiation in  
open_file_ntcreate, and updates deltest17 to allow it to pass against  
win2k3/xp.  This makes open_file_ntcreate more closely match the  
semantics in open_directory and rename_internals_fsp.  This change  
also does not break any other tests in BASE-DELETE or "make test".   
Specifically test deltest20b which verifies the CIFSFS rename DOC  
semantics still passes :).

The second patch cleans up by removing all of the code that is made  
obsolete by the first patch.  It should cause no functional changes.

I know the DOC on close semantics are complicated and delicate, so I  
would love some feedback before I push these patches.

-Tim