![]() Thanks for the trace! I see a few small differences between the two, so let's test one after the other:ġ. The file I copied/synced is just called Test1.txt in folder Test. Here is the strace of FFS and I could confirm that when syncing/copying a single file it will get the time stamp of the sync time on the receiving end and not the original time stamp: Here is the strace for the copy command with preserving the time stamps, which works: I did a test on a single file as requested and below are the link to the straces. Thank you so much for creating FreeFileSync! Hope this is enough info to find the bug! This only seems to be happening when I do syncs to a NTFS external disks. ![]() ffs_tmp files are 0 KB in filesize, and carry the name of the one of the just synced video files. FreeFileSync deletes a few and creates a few new temp files after each sync, which need to be deleted at the next sync. When that is done and I click "Compare" again, it finds a few new temp files of the same type to delete. ffs_tmp files that have to be deleted manually after each sync, or by clicking "Synchronize" again. Not only that but FreeFileSync is also now creating several empty. Maybe a time stamp issue? I'm on a Windows XP SP3 laptop with all updates installed. And those are mostly video, audio and PDF files that don't change at all. But then after I click "Compare" for the 2nd time, it still finds those same files as needing updating. So I click "Synchronize" and let it update them again. Since v6.12 FreeFileSync, after a sync finishes, and I press the "Compare" button again (just to check if all went well), FreeFileSync keeps finding ~5% of the files it just synced as still needing updating. If the external disk or USB key are formatted with FAT32, everything works perfectly. I just wanted to point out a bug that occurs only when syncing to NTFS external disks (external HDDs and Flash-memory USB keys). ![]() I use FreeFileSync every day it's incredible!
0 Comments
Leave a Reply. |