During file Mirroring, right side files get current date and timestamp

Posts: 5 · lbyler 5 Jul 2018, 05:05

I use the Mirror synchronization setting with Comparison Variant "File time and size". I've been doing this for years. Until recently, if you synchronized, then did another compare, FFS would report "All files are in sync". Within the last few weeks (10.1 timeframe?), the right side timestamp is set to the time of comparison, not that of the left side file. The result is that files that have been synchronized appear unsynchronized the next time the same comparison is run, and so are mirrored again.

I have not changed any settings, at least not any that I'm aware of.

I've attached a small example. The 2016 files are from the left side, the files time-stamped today are from the right side. They are three of a list of 19 files which show up as miscompared immediately after completing a comparison.

Is this a new "feature" or am I doing something wrong?

Posts: 7212 · Zenju 5 Jul 2018, 08:13

You mean "time of synchronization". It's possible that setting the target file modification time fails, in which case you'll get a warning message which is also reported in the log.

Posts: 5 · lbyler 5 Jul 2018, 21:30

Thanks for the quick response.

I just tried again, on the same three files as in yesterday's example. The target file timestamp was updated to the current time (today). From the log, it looks like there was no error reported.

Is there anything else I can try? Is there perhaps a configuration switch that enables a more detailed log, say for debugging?

Posts: 7212 · Zenju 6 Jul 2018, 09:10

It's also possible that some other program, e.g. AV, is changing the time stamps:
https://freefilesync.org/faq.php#different-after-sync

Is there anything else I can try? Is there perhaps a configuration switch that enables a more detailed log, say for debugging? lbyler, 05 Jul 2018, 21:30

Yes, this would be Process Monitor: https://freefilesync.org/faq.php#trace

Posts: 5 · lbyler 9 Jul 2018, 05:12

I have more data now. I'm not sure what it means; perhaps you are. I should mention that everything I'm about to describe takes place on one computer (Win 7 Home Premium, 64-bit, up to date), using the same .ffs_gui backup script.

I back up a lengthy file, say an .iso file, without observing the target file directory. The target file gets the current time stamp (the error condition.)

I open a directory window on the target file so I can observe it during backup. I then re-run the backup script. I see the temporary new file and the existing file. At the end of this backup, the old file is deleted and the temporary working file is renamed and given the correct time stamp. The problem is now solved for at least this file. But the difference is that I had a directory window open to watch the backup. (I did this to capture the files during backup and the error timestamp afterward. But the error did not occur.) I do not know what this means, if anything, it's just an observation.

However, for a short file (see attachments) it works differently. I do not have time to take a screenshot of the working new file. But following the transfer, the new files are assigned the CORRECT timestamp for about 3/4 second (the "after(1)" attachment). The files are then set to the INCORRECT (current time, "after(2)" attachment) timestamp.

Does this help?

Posts: 7212 · Zenju 9 Jul 2018, 07:43

Yup, sounds like https://freefilesync.org/faq.php#different-after-sync