qertlu.blogg.se

1. #WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS 64 BIT#
2. #WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS UPDATE#
3. #WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS CODE#
4. #WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS WINDOWS#

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.A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. I cannot comprehend the concept of savingĪ 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 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.

#WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS WINDOWS#

#WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS UPDATE#

On Windows 7 Pro and it is still completely up-to-date according to the Windows Update tool. 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 I had given up and forgotten about this sometime during the past 4.5 years. The file system bug to Microsoft, I'll gladly add it there. However, if you are willing to provide a link where I can report 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īeen 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. The first item is clearly a problem with Windows Explorer itself. There is no possible way this behavior is correct. 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.log, etc.) so it cannot be a date that was embedded within the file as it would with things like media files. Sometimes it matches the value inĭate Modified, but for other files if matches Date Created instead. The Date column in Windows Explorer (as opposed to Date Modified orĭate Created) does not display a reliably predictable date.There are really two different bugs here as well:

#WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS CODE#

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Įven happens if I create (or re-create) the file using output redirection in the command shell.

This is an issue in either Windows Explorer or in the file system itself. When the Explorer and the create date bugs are combined, it can make it VERYĭifficult to find the "new" file in a folder! 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. (Last Modified is correctly changed when my program writes the file.) The Date column in Explorer seems to be showing theĬreate date instead of the more expected Last Modified date and enabling those columns appears to confirm that fact. It appears to be the date the file was originally created aboutĪ year ago.

#WINDOWS EXPLORER NOT UPDATING FILE TIME STAMPS 64 BIT#

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. The output file is opened using the following line of code: hFile = CreateFile( szOutputFile, I have a program that writes some output to a file with the default name of "output.txt"