FAT vs. NTFS

Currently Windows computers use two different file systems: FAT (I am including here the enhanced FAT32 used in most Windows 98 systems and many Windows 95 computers) which is supported by Windows 95/98 and NT, and NTFS which is directly understood only by NT. Notice that each volume (say each physical or logical disk) has its own file system and even if you are running under Windows 9x you may be using a NTFS volume through a network and, on the other hand, you may have in your NT workstation floppies, Zip and Jazz drives, for instance, use FAT (not to speak of some networked drives, or even a local hard disk formatted under FAT for some reason). Apparently all zip files use the FAT conventions.

The trouble is that FAT and NTFS save time stamps with different precision and deal in very different ways with daylight savings.

Time stamps are stored with very high precision under NTFS, but are rounded to the nearest multiple of 2 seconds when saved to a FAT volume. If you keep the source and target files on volumes with different file systems, even after and Update, the next Scan might report that files are different because they have slightly different time stamps.

To avoid this problem, if you keep original files and copies under different file systems, you should set the Ignore time differences under option in the Options dialog box to a value of 2 seconds. This value will be used only when comparing files under different file systems.

As for the daylight savings problem, this is Microsoft's official opinion (Article ID: Q129574):

When Windows NT automatically adjusts for daylight savings time, the times on files on Windows NT file system (NTFS) partitions and the events in the event logs are retroactively shifted by one hour, even though the files and event records were created before the daylight savings time change.
NOTE: To configure Windows NT to automatically adjust for daylight savings time, run Control Panel, choose Date/Time, and select "Automatically Adjust for Daylight Saving Time."
This behavior occurs because of the way that Windows NT stores time information. All times displayed in Windows NT for event log events and files on NTFS partitions are computed as offsets to Greenwich Mean Time (GMT). When you set the time on your system, you are setting the value for GMT. When you select your local time zone for the system, the appropriate number of hours are added or subtracted to the stored GMT value. This adjusted time is displayed. When "Automatically Adjust for Daylight Saving Time" is selected, an additional hour is added to GMT during daylight savings time (the first Sunday in April through the last Sunday in October).
If you are viewing another machine remotely across one or more time zones through Event Viewer, the times for events on the remote system appear relative to your local time. In other words, if you are viewing an event remotely that actually occurred at 8:00 PM Central Daylight Time, the time displayed for the event on your computer will be 6:00 PM when you view the event from the Pacific Daylight Time zone.
When Windows95 or Windows NT clients access network resources they are passed the GMT time of the file stored on the NTFS partition. When the client receives the time stamp in GMT they then adjust the time stamp (+) plus or (-) minus the time zone they are set for.
In the case of WINDOWS NT - it also adjusts for daylight savings time and displays the file's time stamp for the correct local time including Daylight Savings Time setting.
In the case of WINDOWS95 - The time returned by the file system is not adjusted for Daylight Savings Time. This feature is by design, and was implemented to work with servers such as NetWare that do not support the Daylight Savings time APIs and time functions in Windows 95. In this case the files will display off by one hour. this is BY DESIGN for WINDOWS95 clients.

In my opinion, the summary is that Windows 95 is flawed by design and Windows NT has a buggy implementation (because the one hour shift is made based on the current time and not on the time being adjusted). It is not surprising that comparing files saved under file systems with different bugs is not an easy task.

In my opinion the best way to deal with this problem is to disable the "Automatically Adjust for Daylight Saving Time" option in Control Panel/Date/Time in your NT computers. After all, changing the time twice in a year is not that difficult, and it may be automatically done if you use one of the many free programs that set you system clock by reading the time from Internet by using SNTP or another protocol.

I have not been able to devise a full fix for this problem for users that, for some reason, want the "Automatically Adjust for Daylight Saving Time" option selected. To fix it, the program would need to know if the one hour shift was included in the file stamp of the copy, and to do this it should know if the daylight savings were active when the last copy from one file system to the other was made. But how could the program do that? Win32 saves three time stamps for each file, but none can be used to know when the file was synchronized: the creation time tells us nothing about further copies, the last access time may be due to a read operation and the last modification time is automatically (and correctly) reset to that of the original file by most copy routines, including the shell functions used by Directory Compare.

However, I have implemented a partial cure for the problem: if the Ignore differences of 1 hour when comparing FAT and NTFS volumes is selected, the program will flag as (nearly) equal two files under different file systems if their time stamps differ by just one hour (plus or minus the number of seconds, usually 2, in Ignore time differences under). To make clear that it is not completely sure that their time stamps are essentially equal (after all, there is a very small probability that one file was modified, without changing its length and attributes, exactly one hour after the last change in the other) instead of the = sign a # will be used in this case. Unfortunately this is not a perfect solution, because it is of no help for files whose true last modification times differ by less than one hour: due to the one hour shift of daylight savings, the program might decide that the more recent file is older than the other; but as explained above there is no way (to the best of my knowledge) for the program to know which is really older.