Currently we cancel any pending operation on a disconnecting connection,
even it's not the last connection (with multi-channel).
If an unfinished open waits for an oplock break, it
should be possible to resume that operation on new channel.
Mark as regression in order to remember it for 4.13.0 if possible
Replays on pending creates should return FILE_NOT_AVAILABLE?
I think I basically know now how the create replay detection is supposed
to work with pending opens.
I found the key hint in this presentation on page 24:
The key point is that the server should return STATUS_FILE_NOT_AVAILABLE
as long as the open is still processed and the server detects a channel
failure after the client.
The strange thing is that [MS-SMB2] doesn't document this:
My tests against Windows revealed that the server code returns
NT_STATUS_ACCESS_DENIED instead of NT_STATUS_FILE_NOT_AVAILABLE.
When SMB2 leases are not used and only oplocks, then the replay is not
detected at all and I'm getting NT_STATUS_SHARING_VIOLATION after 35 delay.
However I added test code to disconnect a connection when we get a create
without replay flag, then I delay the request by 35 seconds.
During that periot I return NT_STATUS_ACCESS_DENIED to
the replay attempts from the client in order to simulate the
Windows server. The Windows client reports that ACCESS_DENIED to
the application (e.g. explorer).
I changed the server code to return NT_STATUS_FILE_NOT_AVAILABLE,
in that case the Windows client retries the operation like documented
<152> Section 18.104.22.168: For the following error codes, Windows-based clients will retry
up to three times and then retry the operation every 5 seconds until the count of
specified by Open.ResilientTimeout is exceeded:
After 35-40 seconds the client reports the successful retry to the application.
I tested that with "smb2 leases = yes" and "smb2 leases = no", in both cases
the client is happy.
Working link (for me):
This bug was referenced in samba master: