[cifs-protocol] DELETE_PENDING behaviour change between Windows 2016 and Windows 2022?

[Volker Lendecke]

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: w2016-no-delete-pending.cap
Type: application/vnd.tcpdump.pcap
Size: 12591 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220407/07bc6b4f/w2016-no-delete-pending.cap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w2022-118-dir-stat-open-delete-pending-01.pcap
Type: application/vnd.tcpdump.pcap
Size: 11593 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20220407/07bc6b4f/w2022-118-dir-stat-open-delete-pending-01.pcap>