Rename replay request semantics on SMB2

Rename replay request semantics on SMB2

[Shyam Prasad N]

Hi all,

I wanted to understand the server behaviour for a specific scenario,
as it was not very clear what the spec says about this.
We recently implemented the ChannelSequence and
SMB2_FLAGS_REPLAY_OPERATION header flags, which we did not do earlier.

After this, if there is a channel disconnect, and some requests are
in-flight, we are now retrying the same operation with the replay flag
set. The expectation was that the server sees this as a replayed
request, and responds to it accordingly.
However, it looks like it may not be that simple.

I noticed during my tests that when a channel is disconnected in the
middle of a rename compound operation, and the client replays this
again on another channel, the server returns STATUS_OBJECT_NOT_FOUND.
I would have expected a following replay to get this error if it was
not a replay request. But for replayed requests, my expectation was
that the server returns success, even if the rename had completed.

Re-reading through the spec, it looks to me like these (chan-seq-num +
replay) may only be used to maintain ordering of operations, and seems
to concern the ordering of ONGOING operations, and not the ones that
have already completed.
So if a rename operation completed, but the server could not send the
response back, regardless of the replay flag, the server is going to
treat this as a new rename.

Does this mean that the client needs to be aware that the server may
already have completed the prev operation and handle
STATUS_OBJECT_NOT_FOUND only for rename requests?
I would imagine similar handling needed for all non-idempotent requests.

-- 
Regards,
Shyam