Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I created two files at around the same time through Windows Explorer (on Windows Server 2008 R2).

  • a.xlsx (Created at 16:42)
  • b.xlsx (Created at 16:42)

I then duplicate a.xlsx using copy-paste, to get a third file

  • a - Copy.xlsx (Created at 16:45)

If I delete the original a.xlsx and rename a - Copy.xlsx to a.xlsx, I can see the created time in Explorer change in front of me from 16:45 to 16:42, the time of the original.

Can anyone tell me whether this is an issue or design feature with NTFS, or why it is happening?


  • I confirmed the same behaviour on a friend's Windows 7 machine.
  • I tried doing the same through cygwin bash shell and the created timestamp still jumps back in time. So I expect this isn't Explorer's fault.
  • If I just delete the file and replace it with a brand new one of the same name, I also see the time skip backwards to the original. (The created time is show as recent when New > File waits for me to give a name, then old when I name it after the old file.)

Thanks in advance,


share|improve this question
I see the same thing using Explorer on Windows 7 with NTFS. Very strange. – Fran Jun 13 '12 at 16:21
up vote 3 down vote accepted

That is by design. If a file is created with the name of a just-deleted file, timestamps, attributes, and security are carried forward.

Reason: Plenty of apps delete and recreate on saving, as opposed to truncating the existing file and writing the new contents. This feature fixes the (for the user unexpected) behaviour that security settings and all that suddenly disappear.

share|improve this answer
Thanks Felix do you know if this is documented anywhere? – Andyrooger Jun 15 '12 at 13:33
Brilliant, thanks! – Andyrooger Jun 18 '12 at 11:52

I independently tested and confirmed this issue on a Windows 7 machine. I then performed the same test on a linux machine and did not receive the same error. The error only occurs on Windows based machines from my test. As Microsoft is the creator of NTFS I cannot say whether it's intentional and either the feature was simply not added to linux based NTFS file systems, or whether it's an actual bug.

My guess is that this is a bug. However it's surprising that if it is it's lasted in the Microsoft platform for so long.

share|improve this answer

Your Answer


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.