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