` Jeremy Allison wrote:
On Fri, Aug 26, 2011 at 04:15:04PM -0700, Linda Walsh wrote:
Yes... more than one person has noticed it...
I think it has to do with SMB2 keeping multiple descriptors open in,
perhaps, a cache,to the same file...
----
Like a 'fake-level-II oplock cache' ???
either that, OR Window''s request to release the lock is getting
lost or perhaps, just
delayed, so the rename attempts to manip a locked file (thus fail)...
--- um....
No, it's just a bug in the SMB2 server code, not a client issue.
----
Didn't think I implied it was a client issue -- I certainly didn't
think so..
Just the way the client sends calls under smb2 is 'different', than under
smb1, and .. thought samba might be losing the unlock request, not
noticing it; or not changing it to a some weaker form of oplock...
Most like the later -- not noticing or respecting it's a "FAKE
oplock?!?!"...GADS!
Next in SMB3: psychic oplocks that can change state depending on
what the user really meant to do...
-l
Note this inside smbd/smb2_setinfo.c:
if (file_info_level == SMB_FILE_RENAME_INFORMATION) {
/* SMB2_FILE_RENAME_INFORMATION_INTERNAL == 0xFF00 +
in_file_info_class */
file_info_level = SMB2_FILE_RENAME_INFORMATION_INTERNAL;
if (fsp->oplock_type != FAKE_LEVEL_II_OPLOCK &&
fsp->oplock_type != NO_OPLOCK) {
/* No break, but error. */
tevent_req_nterror(req,
NT_STATUS_SHARING_VIOLATION);
return tevent_req_post(req, ev);
}
}
The NT_STATUS_SHARING_VIOLATION error is correct for exclusive oplocks, but
wrong I think for batch oplocks. I'm currently compiling an smbtorture test
case to test this (we already test the exclusive oplock case).
Shame this didn't get caught on the release candidates, but we've
got it now and it'll be fixed in 3.6.1 (along with one other "interesting"
SMB2 bug :-).
More when I've tested and tracked down the specific issue.
Cheers,
Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
