5.2 Bug? Incorrectly reads file modification time?

Get help for specific problems
Posts: 3
Joined: 29 Aug 2013

minnbob

I'm trying to synchronize between a USB thumb flash drive and my C: drive and having problems. FreeFileSync is telling me that files are different when I know that they are the same. I believe that FreeFileSync is incorrectly reading the modification time on one of the files. I reached this conclusion from the following troubleshooting steps:

1. I first erased all of the data files and folders from the C: drive.
2. I then used Windows Explorer to copy all of the data files and folders from the flash drive to the C: drive. At this point there should be identical copies on the two different drives.
3. I then used FreeFileSync feature to compare the two sets of files/folders. FreeFileSync shows many files as being different with the differences being that the modification time on the files on the C: drive is one hour less than the modification time on the flash drive.
4. Further investigation using Windows 7 Explorer shows that the modification time on the C: drive is correct and the same as the modification time on the flash drive. In other words, Windows 7 shows the modification time for the two files as exactly the same but FreeFileSync incorrectly shows the modification time on the flash drive as being one hour later then it actually is. So for example, Windows 7 shows the modification time for both files as 3:04:45 while FreeFileSync shows the modification time on the C: drive as 3:04:45 and the modification time on the flash drive as 4:04:45.
5. HELP!!

Thanks,

Bob N. (Century College, White Bear Lake, MN)

PS Love freefilesync and have been using for many years with no problems until now!
User avatar
Site Admin
Posts: 7058
Joined: 9 Dec 2007

Zenju

The problem occurs when you copy the files with Windows Explorer instead of FreeFileSync. FFS encodes additional data to a file in order to fix the age old FAT design bug of storing local file times instead of UTC. Explorer doesn't know of this additional data, and just copies the file times as it sees them currently. The result is a multi-hour offset when comparing with FFS (which considers the DST-fix on the FAT side), but also in Explorer when the DST switches half a year later.
Solution: Use FFS for the initial copy, or just sync once with FFS later.
Posts: 3
Joined: 29 Aug 2013

minnbob

Hi Zenju,

First, just contributed 7.5 euro ($10) to your effort. Thanks for your tireless effort!

Second, thanks for your explanation and reply. I appreciate it.

Please take what I'm going to say next with a grain of salt. I did read through your explanation and do understand what's going on. I'm still very bothered by the fact that freefilesync is showing some identical files as being different. Maybe it shouldn't bother me and maybe I should just use your fix, but fundamentally I want my software to work with my OS, even if my OS is flawed. When the software doesn't, I lose confidence in it. I'm afraid that that is where I am right now with freefilesync and unless you indicate that a future version will fix this, I'm going to start looking for another program.

Thanks again,

Bob N

PS Please feel free to delete this post after reading. Wanted to email you directly but couldn't find your address.
User avatar
Site Admin
Posts: 7058
Joined: 9 Dec 2007

Zenju

@Bob N:

I understand how you feel. This is exactly the reason why basic design bugs like the Windows decision to store local time in FAT are of the most severe kind. An application in the next layer of the softare stack, like FFS, just can't solve them, but apply hacky workarounds at most. The only real solution is to not use FAT but NTFS, which does the right thing and stores UTC.

PS:
> I'm still very bothered by the fact that freefilesync is showing some identical files as being different.

Just wait half a year, and roles will be reversed: FFS will still show both sides as equal, while explorer "mysteriously" now exposes an 1 hour offset. Explorer is not used for synchronization, so it's more important that FFS has stable file times, even at the cost of user confusion when he compares with Explorer.
User avatar
Posts: 2291
Joined: 22 Aug 2012

Plerry

As a workaround, you might want to look into using the FileTimeTolerance
parameter (see the FFS Help), which can help you bridge the "gap" of 1 hour.