[cifs-protocol] [EXTERNAL] DELETE_PENDING behaviour change between Windows 2016 and Windows 2022? - TrackingID#2204070040007396

[Kristian Smith]

Hi Volker,

I'll be the engineer helping you with this issue you posed last week. 

I looked through the network traces you provided and noticed that the file paths were complete on most requests on the 2016 trace, but just 'x' was used on the 2022 requests. I've included a screenshot for reference. 

Can you please help me by gathering traces from your Server 2016 and 2022 machines with our t.cmd tool as well (instructions follow)? I'm hoping that you will be able to setup the file paths the same way on both requests so that I can compare apples-to-apples.

Collecting traces with t.cmd

	1.	Rename t.txt to t.cmd (file is attached)
	2.	Open Command Prompt as Administrator (PowerShell works too, you just need to run cmd when it opens)
	3.	Navigate to directory of t.cmd
	4.	Run t.cmd srvon
	5.	Reproduce the error
	6.	Run t.cmd off
	7.	Drop the .cab file in the repo via link provided
		a.	https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiN2EzZWEzYTItZTU5Mi00NDUzLTkyZWUtODQ4ZmU0NzcyY2UzIiwic3IiOiIyMjA0MDcwMDQwMDA3Mzk2IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiIzMGVkZDJmYS1mY2VlLTQzMDktOWI3Ni0yNTg3YzNkMWFlNjciLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NTc0ODE4MTMsIm5iZiI6MTY0OTcwNTgxM30.pvUXrQAAePKz-rZYmoDlV5N-2sbh_UrWRwGvavt5MReeDRoLZLWJDkIroj84LMH3fkYeXCS20pR-uSj-TTkp9gaE8Iym1bYGHCr7agQxsDYnXh1bwtpOX5v6DCnlOx-uvzd735X-zA5jgqoLewyugxCN0PNskTHkfK0CO58t3GgbZr1vcQrh2aCzK8VpddSxXok2yhDSc3-d1xWdip54lLIuSk98r7ElRxS8bU0ngkd3ZVw_S_ioUBejY1PNubSBsqPd0_TSJwxy7XlbPUwK6i7GDuGHwyh4vI1AYpUYobh1JDJed4ArHiasC6XUNP1DiF6h-K_FiOUpZpQxDuUeVw&wid=7a3ea3a2-e592-4453-92ee-848fe4772ce3
	8. 	Repeat for other machine

Let me know if you have any issues with the trace collection. Hopefully we can get to the bottom of this quickly.

Thanks,
Kristian


Kristian Smith
Support Escalation Engineer
Windows Open Spec Protocols
Office: (425) 421-4442
kristian.smith at microsoft.com 



-----Original Message-----
From: Jeff McCashland (He/him) <jeffm at microsoft.com> 
Sent: Thursday, April 7, 2022 11:04 AM
To: Volker.Lendecke at sernet.de
Cc: cifs-protocol at lists.samba.org; Jeff McCashland <jeffm at microsoftsupport.com>
Subject: RE: [EXTERNAL] DELETE_PENDING behaviour change between Windows 2016 and Windows 2022? - TrackingID#2204070040007396

[DocHelp to BCC, support on CC, SR ID on Subject]

Hi Volker,

Thank you for submitting your question. We have created SR 2204070040007396 to track this issue. One of our engineer will respond soon.

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C01%7CKristian.Smith%40microsoft.com%7C20c103cfd3654e1fc30208da18c10d52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637849514680452666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6ctwMFRN7%2Bz%2BxaAwBvhmp5wUYChEAthbIipOUQyq7jk%3D&reserved=0 | Extension 1138300 We value your feedback.  My manager is Stacy Gray (stacygr), +1 (469) 775-4055

-----Original Message-----
From: Volker Lendecke <Volker.Lendecke at sernet.de>
Sent: Thursday, April 7, 2022 7:52 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [EXTERNAL] DELETE_PENDING behaviour change between Windows 2016 and Windows 2022?

Hello dochelp,

attached find two network traces that show different delete_on_close behaviour between Windows 2016 and Windows 2022.

The Win2016 trace can open a directory "x" that is held open but already deleted. The directory was created with frame 32/33, it was then opened (and held open) in 47/48. It was then "removed" or rather marked for deletoin with frames 56-62. With frame 64/65 you can see that an open with just FILE_READ_ATTRIBUTES access mask success fine.

The Win2022 trace does pretty much the same, however in frames 58/59 we get a DELETE_PENDING.

I'm asking because right now Samba behaves like Win2022 and some customer application fails with this behaviour.

We could not find an explanation for either behaviour in neither [MS-SMB2] nor [MS-FSA].

Can you explain where in the docs we could find which of the two behaviours is the correct one?

Thanks,

Volker Lendecke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Server2016-2022_trace.png
Type: image/png
Size: 158410 bytes
Desc: Server2016-2022_trace.png
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220411/07dd5c21/Server2016-2022_trace.png>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t.txt
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220411/07dd5c21/t.txt>