summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Prouty <tprouty@samba.org>2008-12-07 10:30:01 -0800
committerTim Prouty <tprouty@samba.org>2008-12-09 18:02:31 -0800
commita5651848b26719b7f9c06fbc996a369a5d97461d (patch)
tree7aac92ca05392678ddfe3751df8d6221ccfae9e0
parent6e4cc12604f6bcf53961326d497f118dfe5da139 (diff)
downloadsamba-a5651848b26719b7f9c06fbc996a369a5d97461d.tar.gz
samba-a5651848b26719b7f9c06fbc996a369a5d97461d.tar.bz2
samba-a5651848b26719b7f9c06fbc996a369a5d97461d.zip
s3: [1/3] Fix a delete on close divergence from windows and the associated torture test
smbtorture4's BASE-DELETE:deltest17 was failing against win2k8, win2k3, and winXPsp2 but passing against samba. 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. To resolve this issue there are three patches. This 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 :).
-rw-r--r--source3/smbd/open.c6
1 files changed, 2 insertions, 4 deletions
diff --git a/source3/smbd/open.c b/source3/smbd/open.c
index 078b47a1a7..8882e5438b 100644
--- a/source3/smbd/open.c
+++ b/source3/smbd/open.c
@@ -1984,10 +1984,8 @@ static NTSTATUS open_file_ntcreate(connection_struct *conn,
fsp->oplock_type, new_file_created);
/* Handle strange delete on close create semantics. */
- if ((create_options & FILE_DELETE_ON_CLOSE)
- && (((conn->fs_capabilities & FILE_NAMED_STREAMS)
- && is_ntfs_stream_name(fname))
- || can_set_initial_delete_on_close(lck))) {
+ if (create_options & FILE_DELETE_ON_CLOSE) {
+
status = can_set_delete_on_close(fsp, True, new_dos_attributes);
if (!NT_STATUS_IS_OK(status)) {