 | 1 | initial version |
i.e. it's not a big deal if someone's Windows Explorer doesn't update a file time stamp or display a new file for 4 seconds after it's updated?
Well, that's arguably a problem, because that should really happen sooner...
...but it won't show up as a large SRT for the SMB2 CHANGE_NOTIFY request. As Eddi notes, and as you indicate by referring to the commands as "asynchronous in nature", the time between a CHANGE_NOTIFY request and the corresponding CHANGE_NOTIFY reply can be arbitrarily long. If a request is posted 2019-09-25 at 13:39, but no file in the directory is changed until 2019-10-25, the response will arrive about 30 days later.
The problem you're seeing would be a delay between the change and the CHANGE_NOTIFY reply being put on the network by the server, a delay between the CHANGE_NOTIFY reply being put on the network by the server and being received on the client's adapter, a delay between the reply being received on the adapter and being delivered to a FindFirstChangeNotification()/FindNextChangeNotification() call in Explorer, or between that indication being delivered to the call and Explorer updating the window.
A network trace won't help with the first or third of those. Network traces on both the client and the server (with reasonably synchronized clocks) may help with the second of those. A network trace would only help with the last of those if Explorer has to make further SMB calls to get file information before updating the window.
