Yes, Windows 10 Pro, 64-bit, Polish language version.
OK. I have investigated this problem for a number of hours trying to figure out why on Windows, specifically with a FAT file system, that the modification time values can vary. It turns out that modification times on FAT file systems are written using the local time of the computer (or camera!) that sets them. Moreover these times are translated to UTC times by modern Windows OSes and these times are cached. To make things even more difficult, these times are cached such that the transition from standard time to daylight savings time does not necessarily take effect when it should.
I eventually stumbled across this document from Microsoft:
https://msdn.microsoft.com/en-us/library/ms724290.aspxThe FAT file system records times on disk in local time. GetFileTime retrieves cached UTC times from the FAT file system. When it becomes daylight saving time, the time retrieved by GetFileTime is off an hour, because the cache is not updated. When you restart the computer, the cached time that GetFileTime retrieves is correct. FindFirstFile retrieves the local time from the FAT file system and converts it to UTC by using the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, FindFirstFile takes daylight saving time into account, even if the file time you are converting is in standard time.
I have been unable to find a way to get a modification time on a Windows PC that can be reliably mapped to UTC. In my investigation, I repeatedly changed my time zone and the modification times reported by the files would change. If I pushed my clock back to before the daylight savings time change, the modification times would also change.
I tried setting specific modification times on both a Mac and on Windows, and the only cases where the modification time would remain unchanged was when my computer's time zone and daylight savings value were the same as was in place at the moment the modification time was set. If one tries to account for DST (and then change the time in code to fix the delta), it is possible to do the wrong thing. For instance if I set the modification time for a file to some time in the past (when it is in standard time) but the time on my system is in daylight savings time and then later read that time when it is still daylight savings time, it is incorrect to adjust for DST. At another time in the year when standard time is in effect, I may have to adjust in a different direction that cannot be determined because it is impossible to tell what UTC offset was in place when the modification time was set.
Basically, when it comes to disks that are formatted as FAT16 or FAT32 and used in a Windows PC, the modification times can be interpreted with significant error depending on time zone changes and daylight savings time changes.
Other file systems like Windows' NTFS filesystem always use UTC times and are completely unaffected by this issue.
Currently as implemented, incremental ingest errs on the side of copying more files than necessary, but never ignoring something that should be copied.
Given the foibles of FAT file systems, it appears that this is the best we can do without dramatically slowing down the process and using checksums (this would require reading every file on the card to get the checksums) to verify files copied by content rather than by modification time.
-Kirk
