File “Date modified” property are not updating while modifying a file without closing it.

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:


Comments (43)
  1. Anonymous says:

    Has anyone addressed this issue?

    The registry hack "Last Access Timestamp" does not work.

    I have an automation system that utilized both windows 7 and Server 2008R2. The systems write daily log files. These files are not updated unless a user directly opens the file. (At which time the OS throws an error saying the file is already open and you can see the file size grow)

    Meaning that a batch script (using x-copy) designed to copy new logs to the appropriate directories will copy zer0 byte files.

    If there is not a direct fix  is there a work around  to get a certain directory  to update the files in a directory with command line?

  2. dotonthehorizon says:

    Nice to see that Microsoft are on this one.
    Just because they haven’t answered after 3 and a half years doesn’t mean they don’t care.

    Besides, not updating the modified time on a file is onviously very useful, as demonstrated by the screams of outrage on this thread.

    Coming soon: Microsoft optimises away all writes to files to reduce I/O overhead and increase performance.

  3. tsw says:

    Any update on this problem? Any way for us to indicate to the operating system that there are other "special folders" that should be updated normally, like you indicate the user profile folders are?

    We are experiencing this same thing and it's a major problem for us, since our IIS Logfiles constantly show "zero bytes" in size, even though they are in fact filled with data. Thus our log parsing utilities (Urchin 7 in this case) does not read the logfiles in, because it thinks they are empty…

    We have also implemented the hack that you mentioned, to have a program open the file up, thus causing the file size to increase one time so that Urchin will import the data. However, we would like Microsoft to offer a better solution that doesn't require a workaround.

  4. Benjamin A says:

    We have the same problem.  Is there any solution to force Windows to report the correct modified timestamp even if it means more disk I/O?

  5. Josh says:

    I run this before my log parser kicks off.. it will do a directory listing of each file from today and that causes the file size to update.. not necessarily the modified date, though.

    for %i in (1 2 3 4) do for /f %G in ('"dir /b \web%iiislogu_ex%date:~12,2%%date:~4,2%%date:~7,2%.log /s"') do dir %G

  6. Harvey says:

    any solution to this? we are seeing exact same issue.

  7. paul says:

    Simple solution:

    1. Right click the "Date" button field on top where the wrong date is showing. (not the file but the header for that column)

    2. then choose "date modified" then right click again and uncheck "date"

    The "date" you are looking at is the for "date taken" or "created" change it to "date modified" and you should be good

    worked for me

  8. jim says:

    Still looking for a solution to this issue – our backup software monitors the filesize of the target file and assumes if the size has not increased for 15 minutes that something has gone wrong, needless to say that with large files on a slow link our backups fail alot!

    Looking for a script I can run on the server on a 5 minute schedule that will update the metadata or perhaps a Registry key to modify this behavior globally on a server.

    Any help would be appreciated.

  9. stephen says:

    This is absolutely crazy. The 'Last Modified' timestamp property is used in lots of systems and is now no longer reliable. Trying to justify it as a reduction in unnecessary disk I/O is a joke. It is necessary! Other processes often need to know the last time a file was actually modified.

    In our scenario we are pulling IIS log files from a server via FTP. We don't want to pull the currently active log file as it is incomplete. The natural solution is to check the 'Last Modified' timestamp (the 'Created' timestamp is not available over FTP). But IIS keeps its active log file open right till it rolls over and creates a new active log. This results in two log files having exactly the same 'Last Modified' timestamp – the active one and the previous one.


  10. Anonymous says:

    Pingback from Hives and Tools and Timestamps….. oh my! | Hats Off Security

  11. Juergen says:

    Seems that this won’t get fixed?

  12. Chris says:

    Experiencing exactly the same issue… even files that have definitely changed and re-named are showing completely wrong times. The issue seems to be intermittent.

    Microsoft.. Can you help? maybe if you spent more time fixing bugs than making up names like ‘Microsoft Reduce Customer Effort Center’ you wouldnt need to make the names up in the first place 🙂

  13. Bill W says:

    We’re having the same problem where app logs in an Enterprise environment are not updating until opened or accessed. This information is sometimes critical for our systems.

  14. nguyen says:

    Winblows as we often call window. Linux/Mac OS is much more reliable.

  15. nguyen says:

    Winblows as we often call window. Linux/Mac OS is much more reliable.

  16. GAAAAAAYYYY says:

    you gotta be kidding me.. windows 7 and windows 8 is not for people who work on computers

  17. GAAAAAAYYYY says:

    you gotta be kidding me.. windows 7 and windows 8 is not for people who work on computers

  18. Straight says:

    What about Windows Server 2008R2? Same issue there.

  19. shunmuga prabu kumar says:

    hey guys same issue occurred in my system also, i find the solution , that is the not a software problem, that is hardware problem, kindly check motherboard CMOS battery slat.

  20. Travis Gibby says:

    I’m having the same problem. Why hasn’t this been fixed???? This is ridiculous.

  21. Resuna says:

    Why isn’t in-core metadata updated first, and that used to maintain internally consistent on-disk metadata? Here’s a good book on how another team managed the problem in UFS with SoftUpdates:

  22. Krzysztof says:

    We need this fixed !!

  23. la_bruin says:

    By adding the "Date last saved" column seemed to work for me.

  24. Arther Daley says:

    Why did M$ make this change to the OS behaviour?

    Don’t come back with I/O improvements as that is bull$ and you know it.

    Are M$ to be trusted? Are there other reasons this has been done?

    Why do problems like this go on for YEARS? Are M$ to be trusted?

    I trust Arther Daley more. Oh dear. Linux beckons again.

  25. EN ES AY says:

    They did it for us. We made them. Sorry about all your apps that monitor this property. Oh well. Now all your apps are belong to us!!!

  26. shunmuga prabu kumar says:

    hey guys, same issue here. it is not a system error though. i did find it wasn’t also a software problem so i fixed it by pressing eject on my cd ROM drive then I put an old VGA cable into the back of my monitor and i stirred my pot noodle with the other
    end and kindly the problem is fixed. Thanks again MicroShaft.

  27. shunmuga prabu kumar (from 2003) says:

    hey guys I fixed this just by simply going in back timing to 2003. the fix I mentioned above also working kindly but also kindly don’t leave the vga in the pot noodle too longingly. if you have time machine is ok though as they only have beef pot noodle
    in 2003. thanks to all the help it is working again! i thanking you all microshaft!

  28. kimi says:

    hey kimi chen_
    er 14 Dec 2010 12:06 AM is over 4 years ago.
    did you forget? or did vga noodling work ok for you?

  29. kimi chen says:

    Well I’m at M$ so I forgot.

    Don’t believe me? Check out all the other support issues that are unanswered for years and years!

    Happy VGA Noodling!

  30. shunmuga prabu kumar says:

    haha! you guys are so funnying! really it was me who kindly used the CMOS butter slat. only don’t use margarine. only working for me with butter. ok got to go backing to workings. all more problem for shunmuga prabu kumar
    to fux!

  31. EN ES AY says:

    Shunmuga Prabu Kumar,

    You mean FIX!

    Worst Wishes,
    Big Brother (watching you, Shunmuga Prabu Kumar)

  32. shunmuga prabu kumar says:

    No, I did mean ‘fux’.

    Also no using salted butters on CMOS as salting motherboardings and do not go well together!

    thanks for alll microshaft (you are helpings people).

  33. kimi says:

    (me again kimi chen_)

    kimi, the first sentence of your article states, ‘These days, we are monitoring this issue’.

    Any results or conclusions from your monitoring or are you still monitoring this issue? (These days?)


  34. kimi chen says:

    We are monitoring this issue today still even!

    Did you try Shunmuga fix / workaround?

  35. EN ES AY says:

    Shunmuga Prabu Kumar may not be available for the foreseeable future.


  36. EN ES AY says:

    Oh and Arther; it’s actually ‘Arthur’ and not ‘Arther’ so watch it! OK?


  37. We The People says:

    Hey a message for ‘EN ES AY’;

    Hæc est hora vestra te ultro mihi tu prius dixeris!

    Oh and ‘Arther’ is fine by us.

  38. dustin says:

    Hey there,
    just here for supporting this because recently, I’ve discovered this bug on our 2k8 R2 machines (only on the physics, not VMs so far).

    Has anyone made a deeper analysis? Is it appearing on both, VM and physical?
    Really annoying if you gotta check logs everyday..

  39. Krishanu says:

    We’re facing same issue. We tried to check if ‘Date Last Saved’ or ‘Date’ field captures the updated time stamp information but, it does not. Please share if anyone has any solution for this. Thanks.

  40. Tauqir says:

    Update the regfile


  41. I had the same problem with Word 2010 and Windows 7 – after editing a document the "Date Modified" did not update. However, in order to clearly identify which was the latest version of a document I decided to add the date to the File Name. As soon as i
    did this the "Date Modified" updated correctly. For some reason, editing the document itself did not trigger the Date Modified to update, but changing the File Name slightly did.

  42. Takeguma says:

    Here, we tried the "CreateFile/ GetFileInformationByHandle/ CloseHandle" approach and this "NtfsDisableLastAccessUpdate" key, but none worked.

    We’re "touching" the directory, by creating and deleting a dummy file.

  43. NJ says:

    Thank you Paul. It worked for me!

Comments are closed.

Skip to main content