File Date not updating in Explorer RRS feed

  • General discussion

  • I have a program that writes some output to a file with the default name of "output.txt"

    The output file is opened using the following line of code:

       hFile = CreateFile( szOutputFile,
                           NULL );

    Under 64 bit Windows 7 Pro (completely up-to-date according to Windows Update) the Windows Explorer in DETAILS view shows the same date/time for the file before and after my program runs.  It appears to be the date the file was originally created about a year ago.  The Date column in Explorer seems to be showing the Create date instead of the more expected Last Modified date and enabling those columns appears to confirm that fact.  (Last Modified is correctly changed when my program writes the file.)

    I'm curious, though, in the past the CREATE_ALWAYS flag also changed the creation date for a file, because the old file was totally lost and overwritten.  When the Explorer and the create date bugs are combined, it can make it VERY difficult to find the "new" file in a folder!

    Friday, March 8, 2013 3:18 PM

All replies

  • I should add that I've tried manually deleting the file (using Explorer) and the newly created file still gets the SAME CREATION DATE as the previously deleted file.  This bug has existed since XP (perhaps earlier.)
    Friday, March 8, 2013 3:27 PM
  • Hi,

    Due to this is related to the coding issue, it is recommended to post in MSDN forum for help directly:

    Windows Desktop Development

    If you have any feedback on our support, please click here

    Alex Zhao
    TechNet Community Support

    Monday, March 11, 2013 2:50 AM
  • This is an issue in either Windows Explorer or in the file system itself.  I offered a very simple code snippet to be completely explicit in showing how I tested, but the same problem happens with every program I tried (for example, Notepad) and it even happens if I create (or re-create) the file using output redirection in the command shell.

    There are really two different bugs here as well:

    1. The Date column in Windows Explorer (as opposed to Date Modified or Date Created) does not display a reliably predictable date.  Sometimes it matches the value in Date Modified, but for other files if matches Date Created instead.  This is for "plain" files (e.g. .txt, .c, .log, etc.) so it cannot be a date that was embedded within the file as it would with things like media files.
    2. Deleting a file (to the recycle bin, permanently, or even within CMD) and then creating an entirely new file with the same name almost always results in the new file having the old file's create date. There is no possible way this behavior is correct.  Period.

    The first item is clearly a problem with Windows Explorer itself.  The second is likely a long standing problem with the file system or the part of the operating system responsible for creating files (if they are different.)  I've never been able to find any good ways to report actual bugs to Microsoft, so I post here, hoping against hope that Microsoft people actually look at these forums and the bug will get to them.  However, if you are willing to provide a link where I can report the file system bug to Microsoft, I'll gladly add it there.

    Wednesday, March 20, 2013 11:47 AM
  • twenty months later:  I land on this thread trying to figure out why the wrong datetime is displayed in Windows Explorer detail view after I overwrite a file.  It appears date is correct in a command-prompt, and in file-properties.
    Wednesday, January 21, 2015 6:16 PM
  • I'm still seeing the exact problem you describe, almost 3 years later :-(
    Wednesday, October 25, 2017 2:23 AM
  • I had given up and forgotten about this sometime during the past 4.5 years.  After receiving an alert about your comment, I reviewed the thread and tried some of the simple tests I has used previously (as mentioned in my posts.)  I am still running on Windows 7 Pro and it is still completely up-to-date according to the Windows Update tool.  I was unable to duplicate my previous results with any of the following tests this morning:

    • Using a CMD shell to delete file.ext and then use "echo test > file.ext" resulted in a file that showed all three timestamps as the date/time I ran the echo command.
    • Using Windows Explorer to delete file2.ext and then using Notepad to create a new file named file2.ext also resulted in a file with all timestamps showing the moment Notepad created/saved the new file.
    • Using Notepad to create a new file and save it (or using a CMD shell and echo) to replace an existing file resulted in only the Last Saved timestamp being updated to the time the file was replaced.  I cannot comprehend the concept of saving a file that I have not accessed, so I think the Last Access timestamp should also have been updated, but I can at least see why someone might think otherwise -- however, the only argument I can see is if "Last Accessed" is actually strictly "Last Read" (names are important!)

    So, it looks (for the moment, at least) like Microsoft may have actually noticed this long standing issue in the file system and attempted to correct it with one (or more) of the updates/patches over the past 4 1/2 years.

    Wednesday, October 25, 2017 12:16 PM