These days, we are monitoring this issue:
when one was developing a utility that monitors log files as they are updated.
On 2003, opening the log file folder in explorer, you can see the timestamp and files size change before your eyes each time the log is updated.
On 2008, “Last Modified” field on log files is not updated unless another program attempts to open the file or the utility is stopped, even if F5 is pressed to refresh the view.
Explorer gets is information from NTFS, by using a cmd prompt and “dir” we found that the NTFS metadata for the files is not updated until the handle to a file is closed.
Refreshing the information of a FOLDER is just going to go to the (memory resident) metadata cached by NTFS, but querying the file explicitly will force disk I/O to get the properties – this was a design change introduced in Vista to reduce unnecessary disk I/O to improve performance
There are some exceptions to this rule:
- in some, but not all, cases a simple “dir filename” is enough to refresh the metadata
- “special” folders may be treated differently, such as user profiles where we do not expect a large number of files and want to be able to rely on the file data presented
- kernel filter drivers may change the behaviour as by design they “add, remove or
change functionality of other drivers”
As the workaround is for any process to open and close a handle to the log files, a tool was written to do exactly that, plus get the file information, using the following APIs: