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
