Could test get FILE_OBJECTID_BUFFER functions

[gwr]

We observe that Windows 11 now requests a FILE_OBJECTID_BUFFER quite frequently (apparently after almost every SMB2 create) using the following SMB2 functions:

• SMB2_Ioctl / FSCTL_CREATE_OR_GET_OBJECT_ID
• SMB2_Ioctl / FSCTL_GET_OBJECT_ID
• SMB2_GetInfo / FS_INFO / FileFsObjectIdInformation

We also occasionally see requests for a FILE_ID_INFORMATION buffer, containing the same "Object Id", this SMB call:

• SMB2_Getinfo / FILE_INFO / FileIdInformation

I don't see any tests for these information levels. Any server could implement them, and we do, returning a per-file unique value for the Object ID. The test cannot possibly "know" what is a correct value, but it could verify that the value is not all zeros, and could verify that two new files have different Object ID values.

[obaro]

Hi @gwr,

Thanks for reporting this issue. We're taking a look and will update this thread when we include tests for these.

[albvar]

Issue Summary

Problem: I am experiencing a delay of 1-2 seconds per pinned share when enumerating network shares in Quick Access on Windows 11. A Wireshark capture shows FSCTL_CREATE_OR_GET_OBJECT_ID requests resulting in STATUS_INVALID_DEVICE_REQUEST errors. This issue is not observed on Windows 10 machines connected to the same network shares, where no such FSCTL calls are made during Quick Access enumeration. This is happening 4x per pinned share which I am guessing is a retry and giving up after the 4th attempt, contributing to the delays. Enumerating 17 pinned shares can take 8-9 seconds. Any additional insight that can be shared about this?

Environment:

• Client: Windows 11
• Server: NetApp ONTAP 9

Analysis

1. Difference Between Windows 10 and 11:
   • Windows 11 appears to make these FSCTL calls during Quick Access enumeration, whereas Windows 10 does not, leading to the observed performance discrepancy.