smbXsrv_open: intruduce smbXsrv_open_replay_cache to support FILE_NOT_AVAILABLE
Before processing an open we need to reserve the replay cache entry
in order to signal that we're still in progress.
If a reserved record is already present we need to return
FILE_NOT_AVAILABLE in order to let the client retry again.
[MS-SMB2] contains this:
<152> Section 3.2.5.1: For the following error codes, Windows-based clients
will retry the operation up to three times and then retry the operation every 5
seconds until the count of milliseconds specified by Open.ResilientTimeout is
exceeded:
- STATUS_SERVER_UNAVAILABLE
- STATUS_FILE_NOT_AVAILABLE
- STATUS_SHARE_UNAVAILABLE
This works fine for windows clients, but current windows servers seems to
return ACCESS_DENIED instead of FILE_NOT_AVAILABLE.
A Windows server doesn't do any replay detection on pending opens,
which wait for a HANDLE lease to be broken (because of a
SHARING_VIOLATION), at all.
As this is not really documented for the server part of the current [MS-SMB2],
I found the key hint in "SMB 2.2: Bigger. Faster. Scalier - (Parts 1 and 2)"
on page 24. There's a picture showing that a replay gets FILE_NOT_AVAILABLE
as long as the original request is still in progress. See:
https://www.snia.org/educational-library/smb-22-bigger-faster-scalier-parts-1-and-2-2011
A Windows client is unhappy with the current windows server behavior if it
such a situation happens. There's also a very strange interaction with oplock
where the replay gets SHARING_VIOLATION after 35 seconds because it conflicts with
the original open.
I think it's good to follow the intial design from the 2011 presentation and
make the clients happy by using FILE_NOT_AVAILABLE (and differ from Windows).
I'll report that to dochelp@microsoft.com in order to get this hopefully fixed in
their server too).
BUG: https://bugzilla.samba.org/show_bug.cgi?id=14449
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
git.samba.org / kseeger / samba-autobuild / .git / commit