Hi Ralph: When Open.Connection is not NULL and a create is received with replay flag set, the server will return status_file_not_available.
In your case, when you disconnect, the open.connection is set to null and scavenger timer is started as explained in MS-SMB2 section " 3.3.7.1 Handling Loss of a Connection ". When the create arrives with replay, the open.connection is set to current connection, as explained in "3.3.5.9.10 Handling the SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context". When the second replay create comes in, the open.connection is not null and therefore you get status_file_not_available. I'll file a bug to add this processing in MS-SMB2. Please let me know if this does not answer your question. Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Friday, June 27, 2025 10:06 AM To: Obaid Farooqi <[email protected]> Cc: Microsoft Support <[email protected]>; [email protected] Subject: Re: [EXTERNAL] MS-SMB2: Create replay and Persistent Handle - TrackingID#2506160040006768 On 6/23/25 7:25 PM, Ralph Boehme wrote: > Hi Obaid, > > attached is a new set of traces of the PH scenario. Any better? > > I've checked which node hosted the IP, so the t.cmd traces should now > cover the scenario. > > Fwiw, a simplified version of what I'm trying to understand is where > is the STATUS_FILE_NOT_AVAILABLE coming from in packet 38. This is not > covered by the docs unless I'm missing something. I've learned that sending attachments that include .cab files is not a good idea and you likely haven't received my previous mail? I've uploaded the above trace per the portal link you provided. Thanks! -slow _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
