[PATCH]: Fix a delete on close divergence from windows and the
associated torture test
jra at samba.org
Sun Dec 7 07:49:54 GMT 2008
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:
> 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.
More information about the samba-technical