Filetimes in FAT and NTFS

[Spasm]

I am writing a program that needs to check if the filetimes for two files are equal. I was testing it between files on my local hard drive (NTFS) and a USB flash drive (FAT), and it seems that the file times on the flash drive are rounded strangely. Some files are rounded several seconds up, and it doesn't store any millisecond value. This is all fine, I just can't figure out how they are changed when copied from NTFS to FAT. Once I know that, I'll just convert them both to the same thing before I compare them. Can anyone help me out?

[TheCPUWizard]

Unfortunately because in differnces between the internal storage mechganisms of the file systems, it is impossible to tell for certain if two times are identical or not.....

[Spasm]

Well, the FAT files that I am comparing are copies from the NTFS drive. So if I could recreate the changes that a copied file would go through, I could compare that.

[TheCPUWizard]

Well, the FAT files that I am comparing are copies from the NTFS drive. So if I could recreate the changes that a copied file would go through, I could compare that.

Consider....

1) I have a number (integer) between 100 and 999.
2) I tell you the first two digits
3) You tell me the EXACT number that I have.

You very simply CAN NOT.

Now to make it a little closer... Two people give you numbers accoring to the same rule...Did they both think of the Same number?

There is information lost in the transfer.

[Spasm]

I'm making a program that creates a backup of a folder in real time as files are created/modified/deleted (it's pretty easy to do with a FileSystemWatcher). My function that checks to see if a specific file needs to be copied compares the file size and last write times of the two files, and if they're not equal, it uses File.Copy to make a backup.

So the two files I'm comparing are copies. If they're on two different kinds of file systems, the file times are probably going to be different, even though the file was copied. If I convert the NTFS file time to what it [i]would]/i] be if the file were copied to a FAT file system, my function would work properly.

The only strange situation where my function would incorrectly think the files are equal when they're actually different is if this happened: A file is saved on an NTFS drive, and then is saved again on the exact same tick that the NTFS file time would be changed to if it were copied to FAT, but the file has the same size. I doubt that will ever happen to small number of people who are going to use my program, and in fact, I doubt that has ever even happened in the history of computing.

[TheCPUWizard]

Then if you are willing to accept that, I dont see what the problem is, except if the computers are going to be in different time zones.....(or the timezone for a specific computer changes...)

[Spasm]

I just don't know how to do that NTFS file time to FAT file time conversion ~_~

It doesn't just round up to the nearest second, sometimes it rounds up two seconds, sometimes it rounds up just one, I can't figure it out.

[TheCPUWizard]

I just don't know how to do that NTFS file time to FAT file time conversion ~_~

It doesn't just round up to the nearest second, sometimes it rounds up two seconds, sometimes it rounds up just one, I can't figure it out.

Much more lilely you are seeing the results of things being cached across the drives. On busy systems, I have seen timestamps of flash drives that differ by up to a minute from the time I copied the file. Simply the nature of the beast. You would be much bettter of using MD5....

[foamy]

I would consider keeping an internal record concerning each monitored file. From this record you could tell the last time it was copied, and compare that to it's current LastWriteDate (or whatever you're using)...

Just a thought...