"Bug" in version 10.20

[weedenft]

I have been using for a few years without any problems and quite happy with the free version. My needs are for backup and very basic. I updated to the latest free version and when I sync from one drive to a backup drive (I have about 800,000 files) it shows that 200,0000+ need to sync. This doesn't feel correct as I don't have many file changes from month to month. I went ahead and did the sync (took about 14 days) and then ran the sync again and it showed the same 200,000 files needed to sync. This doesn't feel right.

Please advise.

Thanks

[fcoj]

It happens the same thing to me.

[fcoj]

A quick update...
I have tried my old trusty 10.7 Donation Edition and it displays the same "problem".
As soon as a synchronization finishes, if I press Compare, it shows the same list of files to be synchronized.

I suppose there is something related to a Windows update instead of a change/bug in the later versions of FreeFileSync.

I keep investigating...

[fcoj]

Further investigation...

Even if I have excluded a few folders,

1.jpg (175.48 KiB) Viewed 2114 times

they are still evaluated in the comparison.

2.jpg (287.4 KiB) Viewed 2114 times

Am I doing something wrong?

[Zenju]

Probably same issue: viewtopic.php?t=7093

[fcoj]

Hi Zenju, I don't think it is the same issue. The screenshots above are from version 10.22. If you have a look at the third message, I have also tried with an old version, a 10.7 Donation Edition, and the behavior is the same.
I'll try to have a look at the logs to find more useful info for you.

[fcoj]

I have solved the problem on post 5, my fault.
The excluded path was

C:\Users\Me\Pictures\Lightroom\LR-Catalog\LR-Catalog Previews.lrdata

instead of

\LR-Catalog\LR-Catalog Previews.lrdata\

The main problem of presenting the same file to sync, just after a sync is complete, remains.

Further testing...

[fcoj]

I have performed checksum on a bunch of photos of two subsequent backups and the files were exactly the same.
If I can provide any log, please let me know how to do and where I can collect them.

[Zenju]

You should be able to find out why FFS is copying files by looking at the columns in the middle.

And there's also https://freefilesync.org/faq.php#different-after-sync

[Zenju]

Try to reproduce the test case with a *single* file and log with Process Monitor:

1. file update operation
2. comparison that shows that 1) was unsuccessful

[Zenju]

The log looks fine: PROVA_MASSIMO~43f6.ffs_tmp, before it is renamed to PROVA_MASSIMO.ods has lastWriteTime: 20.03.2020 01:51:06, which is the correct value matching the source on C:\. I can't say what is returned in step (2) when you do a comparison again after the sync, as Process Monitor doesn't log the file modification times. Which side is not keeping the date, is it source or target?

[fcoj]

An interesting update.
Having a look at iXSystem forum I have found that there is an issue with FreeNAS with "Modified" timestamps on Windows file copy.

Here is the link:

https://www.ixsystems.com/community/threads/issue-with-modified-timestamps-on-windows-file-copy.82649/

I'm going to investigate deeper to see if there is a solution.
So thank you to Zenju for supporting me with debugging and I can assure there is not a bug on his side related to this strange behavior, the bug or strange behavior is FreeNAS side.

[fcoj]

The solution that worked for me was to go back to FreeNAS-11.3-RELEASE from FreeNAS-11.3-U1.

After a mandatory sync with FreeFileSync, my backup procedure works fine again.

I hope this post can help someone else.

[fcoj]

Final update:

After upgrading to FreeNAS-11.3-U2 the problem was fixed.

Thanks to Zenju for the support.