Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Check this out:

  1. Create a new file on your Windows machine.
  2. Note its creation date/time.
  3. Delete the file.
  4. Wait a little bit.
  5. Create a new file on the same directory, with the same name as the previous one.
  6. The creation date/time of the new file will be equal to that of the previous one!

I have verified this on Windows XP SP3 and Windows Vista SP2 x64. I find it hard to believe that it's a bug. Is it really a bug with the OS? If not, why this behaviour? It's giving me a hard time, since I use the file creation date/time to keep track of backup cycles in a custom app we are developing.

Thanks.

share|improve this question
add comment

4 Answers

up vote 4 down vote accepted

This appears to be a documented feature called File System Tunneling. See http://support.microsoft.com/kb/172190 for details on this and how to disable it via a registry setting.

share|improve this answer
    
Wow, I had no idea about that. Thank you. –  CesarGon Mar 6 '12 at 18:53
add comment

I don't believe this is a bug, I think it's by design. I ran into this a few months ago myself.

Consider an application that creates a temporary, working copy of the file you just opened. As you're working, your changes are written to the temp file. When you're finished and choose to save the file, the application deletes the original and renames or copies the temp file to the original file name. It's not terribly common, but it's not uncommon (many old and simple applications work this way...text editors and the like).

In the above case, every time you saved a file, its creation date would always match last modified!

I dunno what kinda junk is going on behind the scenes, perhaps somebody with some insight will provide more details. As an aside, some file systems don't store creation dates at all, only modified and accessed dates (ext2, for instance).

Update: I found the following from the writers of xxcopy, at http://www.xxcopy.com/xxcopy15.htm , which might apply to what you're doing:

Since the use of the File-Create date has serious problems, we generally discourage the use if this date

Problems with the file creation date (File-Create date),

The problems of the File-Create date can be traced back to the inconsistency in Microsoft's various file management utilities. It seems that the purpose of three distinct
variations in the file date values were never clearly defined by the designer of the feature. We as software developers have not come across any official documents on this subject.

share|improve this answer
    
Thanks, Boden. The xxcopy site is very interesting. –  CesarGon Dec 10 '09 at 1:24
add comment

I would guess that Windows is being lazy and - on seeing that everything else in the new file is identical to the old one - just reuses a file system table entry that had previously been marked for deletion.

This kind of behaviour is actually documented here.

Timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed.

(My emphasis)

Edit to add: I guess you would want to use something like SetFileTime in your app after creating the file.

share|improve this answer
    
Thanks, mh. Using SetFileTime is a good solution, yes. –  CesarGon Dec 10 '09 at 1:24
add comment

I found this with win32 DeleteFile on windows 7 SP1.

Tried a few tricks to make it use the proper 'created' date, but no joy. If you wait 2-3 mins after deleting the file, then create the new one, the date will be correct. Probably need a 'flush all files' win32 routine.

It could cause nasty bugs, pretty iffy thing to do in my opinion, untidy design. The file was deleted, gone, there should be no 'ghosting' like this. If you are worried suggest using win32 SetFileTime.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.