SMB2 CHANGE_NOTIFY 能否用于保存远程目录列表的准确快照？

如何解决SMB2 CHANGE_NOTIFY 能否用于保存远程目录列表的准确快照？

SMB2 CHANGE_NOTIFY 看起来很有希望，好像它可以从服务器提供有关子目录或子树更新的足够信息，因此我们可以通过处理响应来保持我们的远程目录列表是最新的。

然而，它不是对事件流的订阅，只是接收一个响应的一次性命令，所以我怀疑它只能用作使我们的缓存无效并重新读取目录的提示。当我们收到响应时，在发送另一个 CHANGE_NOTIFY 请求之前可能会有任何其他更改，我们会错过这些更改的详细信息。

有什么办法可以解决这个问题吗？或者重新阅读目录以了解它已更新是必要的步骤吗？

我想了解协议级别的可能解决方案（您可以想象我正在使用一个定制的客户端，我可以使用 Windows 或 smbd3 等一些常见服务器来做我想做的事）。

解决方法

严格来说，即使重新阅读目录列表也不会拯救您，因为目录可能会在重新阅读列表和提交另一个 CHANGE_NOTIFY 请求之间发生变化。竞争条件只是移动到不同的位置。

除非没有竞争条件。

这需要一些挖掘，但它在规范中全部都有。在 MS-SMB2 v20200826 §3.3.5.19 'Receiving an SMB2 CHANGE_NOTIFY Request' 中，说明：

服务器必须按照第 3.3.1.3 节中的算法指定的那样处理对象存储中的更改通知请求。

在第 3.3.1.3 节“Algorithm for Change Notifications in an Object Store”中，我们有：

服务器必须实现一种算法来监控对象存储的变化。此算法的效果必须与用于提供 [MS-CIFS] 部分 3.2.4.39 和 3.3.5.59.4 中指定的行为的效果相同。

在 MS-CIFS v20201001 §3.3.5.59.4 ‘Receiving an NT_TRANSACT_NOTIFY_CHANGE Request’中有这样的：

如果客户端之前没有在这个 FID 上发出任何 NT_TRANSACT_NOTIFY_CHANGE 请求，服务器应该分配一个空的更改通知缓冲区并将其与打开的目录相关联。缓冲区的大小应该至少等于用于传输 NT_TRANSACT_NOTIFY_CHANGE 请求的 SMB_COM_NT_TRANSACT 请求（第 2.2.4.62.1 节）中的 MaxParameterCount 字段。 如果客户端之前在这个 FID 上发出了 NT_TRANSACT_NOTIFY_CHANGE 请求，服务器应该已经有一个与 FID 关联的更改通知缓冲区。更改通知缓冲区用于收集引用相同 FID 的 NT_TRANSACT_NOTIFY_CHANGE（第 2.2.7.4 节）调用之间的目录更改信息。

强调我的。这与 how Samba implements it 一致（fsp 结构在各个请求之间持续存在）。我不认为微软会因为不遵守他们在自己的规范中做出的承诺而做得更糟。