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

[Jeremy Allison]

On Sat, Dec 06, 2008 at 06:30:10PM -0800, Tim Prouty wrote:
> 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?

I believe this ended up being a bug in the Windows 2000 DOC implementation
(which was the current Windows implementation at the time I added
the code to test this).  I'm pretty sure W2K does make that differentiation
(which was why I added the change. I remember being pissed off about
having to do it at the time :-).

I think if you test against W2K latest service pack you'll find it
passes deltest17. This was something I've been meaning to go back
and correct for a while, but didn't get to as it obviously wasn't
something Microsoft worried about too much as their regression
tests didn't catch it for WNT -> W2K. I think you're correct, Samba
is currently matching an old Windows bug and needs fixing here.

Do you mind if I get to this early next week ? Stuff to do at
home over the weekend.

Jeremy.