Windows 7 constant refresh of SMB 2.002 directory RRS feed

  • Question

  • I have implemented a non-Windows SMB 2.002 server on a system whose file systems do not support change notify.  The SMB2 specification describes situations where it is valid to return STATUS_NOT_SUPPORTED if the backing store does not provide change notifications.

    Excerpt from section

    "If the underlying object store does not support change notifications, the server MUST fail this request with STATUS_NOT_SUPPORTED."

    My problem is that returning STATUS_NOT_SUPPORTED to a Windows 7 client appears to set the client into a refresh loop on the directory until the Explorer window is closed.  As you might imagine, the rapid file refreshes cause a DOS on the server because of network interface and CPU bottle-necking as well as making it very difficult for the user to perform operations in the Explorer window (like renaming a file.)

    Can anyone explain how to avoid this infinite refresh loop without requiring that the server support change notifications?

    Tuesday, May 10, 2016 4:33 PM

All replies

  • Hi Charles,

    Thank you for contacting Microsoft Open Specification Forum.  We have received the request above.  One of the engineers from the open specifications support team will be in contact shortly. 

    Thank you,

    Nathan Manis

    Tuesday, May 10, 2016 8:18 PM
  • Hi Charles,

    What you describe is not unexpected and not necessarily a protocol issue.  As you discovered, it is reasonable for you to return NOT_SUPPORTED as you rightly do not support that feature.  Keep in mind, however, that the protocol is just a pass through of requests from upper-layer applications: in this case Explorer.exe.  Applications that request a change notification are often doing so to ensure that any contents they are displaying are current using an efficient mechanism: have the server notify that a change occurred.  If this feature is not supported, which is reasonable, the application has a choice: accept that its information might be stale or poll for changes.  Each application makes its own tradeoff as to how to react to this situation.

    It might be possible (via registry setting, for instance), to affect how Explorer behaves.  I don’t know.  There are several Technet and MSDN forums that may be more appropriate to shed light on that aspect.  This forum’s purpose is to discuss protocol implementation issues.  The above discussion is responsive to your protocol question.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, May 11, 2016 7:04 AM
  • Just a quick note that for Windows 7 SP1 you can resolve this issue by setting SMB2_FLAGS_ASYNC_COMMAND in the header of the response (with the status set to STATUS_NOT_SUPPORTED).

    IIRC, this solution does not work for later versions of Windows 10.

    Some additional information regarding client settings:

    EDIT 2019-07-03:

    The suggested reply is not a valid interim response (as per [MS-SMB2], after more testing, I have observed that using this "solution" will cause Windows 7 RTM / SP1 clients to disconnect the connection after 60 seconds (as per [MS-SMB2] Request Expiration Timer Event).

    I'm now testing returning a valid interim response (STATUS_PENDING).

    • Edited by Tal Aloni Saturday, July 13, 2019 2:10 PM Updated information
    Thursday, August 3, 2017 10:40 PM
  • Thank you, Tal, for providing additional information for the original poster.

    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, August 4, 2017 6:49 PM