Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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 have a FAT32 flash drive full of old archived emails, and their creation/modification date is important because it represents when the email was received. I'm trying to copy these over to another computer (Windows 7, with an NTFS filesystem). I copy the files over, and it changes all of the creation/modification dates to the current date/time. I've tried manually copying through folders, using robocopy, and using xcopy, and have the same issue regardless. One strange observation is that, after I do a copy and have the destination folder open, the creation/modification times seem to be correct at first, but slowly convert over to the current time (when I click on a file, it has the correct date/time, but after a second or two changes to update to the current time; very frustrating).

Does anyone know a foolproof way to do copy over these emails while preserving timestamps?

EDIT: I can confirm that when I simply (single-)click on the file, its modified date is updated. Is this happening because the old modified date is newer than the creation date?

share|improve this question

migrated from Jul 10 '11 at 8:31

This question came from our site for professional and enthusiast programmers.

Are you sure its the last modified time you're looking at and not last access time? Last modified should only change if you save the file. Just opening it should not change the modified time. It would change the last access time however. – ribram Jul 9 '11 at 21:32
It's definitely Last Modified – Jay Sullivan Jul 9 '11 at 21:46
Have you tried robocopy /copy:t? – grawity Jul 10 '11 at 9:48
up vote 1 down vote accepted

The changed timestamps are intended since you copied them. Read Description of NTFS date and time stamps for files and folders.

I'm surprised people think Microsoft would break something like this. Considering that they still leave crap like share permissions in Windows for FAT compatibility, they would of course had done everything in their power to help people migrate off of FAT. . .

Probably the biggest gotcha you have to be aware of is that that FAT stores the time according to the local timezone. NTFS stores time based on UTC. Usually it isn't a big deal unless. . . . .

Daylight Savings

When files copy over from FAT to NTFS, Microsoft doesn't calculate whether the FAT faile's timetamp was DST or not. The normal copy/move will assume DST for the FAT file. Thus if your FAT file was created during Standard time, your timestamps will be off by an hour. But if they were DST, you can safely assume they will be fine.

Again, if you don't read the above reference, an excerpt is:

If you copy a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time but changes the created date and time to the current date and time.

If you move a file from C:\fat16 to D:\NTFS, it keeps the same modified date and time and keeps the same created date and time.

share|improve this answer
I'm surprised that this was accepted as an answer, given that you just quoted documentation as saying that "it keeps the same modified date and time" in response to a question that asks why the last modification date is changing. – JdeBP Jul 19 '11 at 13:08
@JdeBP but that IS the answer, or more accurately: "this is expected behavior" – ioSamurai Jul 19 '11 at 13:49
It may be expected behaviour, but it most definitely is not the answer when the question is, as here, why some other behaviour is actually happening right in front of the questioner's eyes. The timestamps are visibly changing. Saying that "It is expected behaviour that the modification date and time is unchanged." is not an answer to the question "Why are they changing and how do I stop what's causing this?". – JdeBP Jul 20 '11 at 12:43
If it isn't the expected behavior, more than likely, it has nothing to do with the OS. With that elimination, they probably found the problem. It isn't a hard concept: finding a solution by figuring out what you don't want. . . – surfasb Jul 20 '11 at 16:33
You make my point for me. If what you wrote didn't turn out to be the answer, then it's surprising that it is accepted as the answer. – JdeBP Jul 21 '11 at 10:39

One mechanism by which the last modification date will "mysteriously" change after a file is created/copied is Windows Explorer. Raymond Chen describes one thing that Explorer does to files after they are extracted from untrusted archives that updates their last modification timestamps. In general, any post-creation/copying modifications to files by Windows Explorer that update alternate data streams will result in this effect. Exactly what modifications can occur depends from what types these files are (You don't say.) and what Explorer extensions you have (You don't say.).

share|improve this answer
While an interesting link, I don't think that is what is happening. These files weren't downloaded off the internet and thus were not marked by Internet Explorer. The mark of the web is explicitly set by Internet Explorer. – surfasb Jul 20 '11 at 16:37
Your horizons shouldn't be limited to just Internet Explorer. They most certainly weren't in what I actually wrote above. Read it again. Any alternate data stream usage by Windows Explorer or an extension will update the timestamp. – JdeBP Jul 21 '11 at 10:37
Internet Explorer is not the same as Windows Explorer (commenting on a comment, but perhaps "Explorer" should be expanded in this answer to avoid any ambiguity(?)). – Peter Mortensen Jan 9 '14 at 12:39
It already says Windows Explorer. Twice. – JdeBP Jan 9 '14 at 13:07

You could try vcopy. It's designed for NTFS, but might work for copying timestamps from FAT32 partitions.

share|improve this answer

It's not possible to copy it because in a FAT32 system the date is stored in file metadata whereas in an NTFS system the file is in a extended attribute record on the system. Windows will just ignore the file date and write a new one.

Certain backup programs may be able to preserve the date, but finding one that does will just have to be trial and error.

share|improve this answer
It is possible to copy timestamps the same way data is copied: read the source timestamp, write it to the destination using SetFileTime(). – grawity Jul 10 '11 at 9:49
And indeed robocopy and xcopy (with the appropriate switches) do exactly that. The question even states that the timestamps are copied, and change a short while afterwards when the files are manipulated from within Windows Explorer. – JdeBP Jul 19 '11 at 13:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .