Strange timestamp duplication when renaming and recreating a file

Question

I'm trying to rename a log file named appname.log into the form appname_DDMMYY.log for archiving purposes and recreate an empty appname.log for further writing. When doing this in Windows 7 using C++ and either WinAPI or Qt calls (which may be the same internally) the newly created .log file strangely inherits the timestamps (last modified, created) from the renamed file. This behaviour is also observable when renaming a file in Windows Explorer and creating a file with the same name quickly afterwards in the same directory. But it has to be done fast. After clicking on "new Text File" the timestamps are normal but after renaming they change to the timestamps the renamed file had or still has.

Is this some sort of Bug? How can I rename a file and recreate it shortly afterwards without getting the timestamps messed up?

Jehanna

I'm seeing the same issue. In my case the code is written in python. Only happening on Windows. Same code, but running on Mac doesn't have this issue. – Saida

Possible duplicate of Unbelievable strange file creation time problem – Gunpaper

Answer 1

This looks like it is by design, perhaps to try to preserve the time for "atomic saving." If an application does something like (save to temp, delete original, rename temp to original) to eliminate the risk of a mangled file, every time you saved a file the create time would increase. A file you have been editing for years would appear to have been created today. This kind of save pattern is very common.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724320(v=vs.85).aspx If you rename or delete a file, then restore it shortly thereafter, Windows searches the cache for file information to restore. Cached information includes its short/long name pair and creation time. Notice that modification time is not restored. So after saving the file appears to have been modified and the creation time is the same as before.

If you create "a-new" and rename it back to "a" you get the old creation time of "a". If you delete "a" and recreate "a" you get the old creation time of "a".

Squib

Interesting to point out the save pattern, maybe this could be more emphasized than "atomic saving" in the first sentence. – Gunpaper

Answer 2

This behaviour is called "File Tunneling". File Tunneling is allow "...to enable compatibility with programs that rely on file systems being able to hold onto file meta-info for a short period of time". Basically backward compatibility for older Windows systems that use a "safe save" function that involved saving a copy of the new file to a temp file, deleting the original and then renaming the temp file to the original file.

Please see the following KB article: https://support.microsoft.com/en-us/kb/172190 (archive)

As a test example, create FileA, rename FileA to FileB, Create FileA again (within 15 seconds) and the creation date will be the same as FileB.

This behaviour can be disabled in the registry as per the KB article above. This behaviour is also quite annoying when "forensicating" Windows machines.

Regards

Adam B

Ethelyn

Answer 3

Here's a simple python script that repro's the issue on my Windows7 64bit system:

import time
import os

def touch(path):
    with open(path, 'ab'):
        os.utime(path, None)

touch('a')
print "    'a' timestamp: ", os.stat('a').st_ctime
os.rename('a', 'a-old')
time.sleep(15)
touch('a')
print "new 'a' timestamp: ", os.stat('a').st_ctime

os.unlink('a')
os.unlink('a-old')

With the sleep time ~15 seconds I'll get the following output:

    'a' timestamp:  1436901394.9
new 'a' timestamp:  1436901409.9

But with the sleep time <= ~10 seconds one gets this:

    'a' timestamp:  1436901247.32
new 'a' timestamp:  1436901247.32

Both files... created 10 seconds apart have the time created-timestamp!

Saida