Showing the same files again even after copying just now

[achandram]

Hi All,

I am using FreeFileSync on Mac OS Ventura 13.1 version. When I sync files, it syncs properly. But, when I click scan again, it's identifying the same files again, even though it copied these files just before this sync. Seems like some issue with identifying the modified timestamp. Is anyone else facing the same issue?

Thanks,
Chandra

[lcush13]

I am also having the same issue on Mac OS Ventura 13.1 I thought it might have been an incorrect setting or something but must be an issue with identifying timestamps.

[therube]

Is it all the files that it is finding again, or only some of them?

Don't know if applies, but, https://forum.scootersoftware.com/forum/beyond-compare-4-discussion/mac/89004-ventura-public-release-appears-to-have-a-serious-file-copy-issue-that-breaks-bc

[lcush13]

Yes, all the files are being found again just after a completed sync. When you start this new sync it updates and overwrites whatever has been found which is a waste of time since I have it configured to mirror and it shouldn't be updating all items. Plus because of the large number of items I am syncing to a drive this takes 10+ hours to complete.

[ILikeYourFace]

This is EXACTLY what is happening to me.

For example, to test this, just now I mirrored from Disk 1 to Disk 2 of my NAS the file `2001. A Space Odyssey (1968).mkv`, both files having a file size of 10.4 GiB and the latter's timestamp now 2026-04-08T01:55:16. (The latter's timestamp *is* supposed to be different from the former's, right? I know, stupid question. Of course it is. Sorry.)

I then hit Compare again and it once again shows up on the list.

---

**OS**: Arch Linux
**DE**: KDE Plasma 6.6.4
**FFS Version**: 14.9 [Donation Edition]

[Plerry]

If identically named left- and right-side files have different timestamps, when Comparing by "file time and size" (FFS's default), FFS will consider such files to be different, even if their size (and even content) is identical.
Depending on your synchronization settings, this "difference" between your left- and right-side file will result in proposed synchronization action, that will be executes when clicking "Synchronize".
E.g. in a Mirror sync, if your right-side file has a different (older or newer) timestamp than your left-side file, FFS will overwrite (update) the existing right-side file by its left-side counterpart.

Depending on the protocol and mounting method you use to connect to a resource, the timestamp of the left-side file can not be preserved when overwriting/updating your right-side file.
In such cases, the updated right-side file gets the timestamp of the moment of updating that right-side file.
This happens e.g. often when connecting the resource via the FTP protocol, but is not limited to that case.
During the next sync, the timestamp of the right-side file will then again be different (in casu: newer), so (in case of a Mirror sync) FFS will propose to (again) update the file right-side file.
FFS tries to maintain the timestamp, but is not able to, due to the used protocol or limitations in the resource's (NAS) operating system.

[ILikeYourFace]

Depending on your synchronization settings

Here is my synchronization settings:

Depending on the protocol and mounting method you use to connect to a resource

I have a QNAP NAS, and it uses SMP.

[ILikeYourFace]

Oops, I accidentally used a temporary file hoster site. Here is actually my synchronization settings:



Also, for some reason, I can't seem to edit my comment (or whatever it's called), so I just wanted to correct myself: I have a QNAP NAS, and it is connected to my computer through SMB. (Not SMP.)

[ILikeYourFace]

Would someone be willing to help me figure this out please? I would be very grateful. :)

[xCSxXenon]

Make sure your QNAP is updated. I've seen timestamps mismatching caused by NAS firware/software.

[ILikeYourFace]

Make sure your QNAP is updated. I've seen timestamps mismatching caused by NAS firware/software.

Okay, I just checked and yeah my QNAP is updated—the firmware as well as all apps. I then did a mirror sync and it said 3.33 TB was needed to be processed (4 new / 8722 updated). I did about 1 TB, then stopped the sync, and rescanned. It once again says I need to do 3.33 TB, or 4 new & 8722 to be updated.

[Plerry]

If you run a Compare and then hoover your mouse over the icon mid between any of the items, FFS tells you why it thinks it needs to take the proposed sync action.
And, as written before, likely the timestamp of the right-side file differs from that of the left-side file, and hence FFS considers those files to be different.

[ILikeYourFace]

If you run a Compare and then hoover your mouse over the icon mid between any of the items, FFS tells you why it thinks it needs to take the proposed sync action.

It only does that when it's a file that needs to be added or deleted. I only have 7 files that are new; the other 8722 files I have are only files that need to be updated, and it doesn't say a reason.

And, as written before, likely the timestamp of the right-side file differs from that of the left-side file, and hence FFS considers those files to be different.

Yeah, it does. As you said earlier, it's probably because of how it's mounted.

Depending on the protocol and mounting method you use to connect to a resource, the timestamp of the left-side file can not be preserved when overwriting/updating your right-side file.
In such cases, the updated right-side file gets the timestamp of the moment of updating that right-side file.
This happens e.g. often when connecting the resource via the FTP protocol, but is not limited to that case.
During the next sync, the timestamp of the right-side file will then again be different (in casu: newer), so (in case of a Mirror sync) FFS will propose to (again) update the file right-side file.

And as I said in reply to that comment, I'm connected via SMB. I also provided a screenshot of my synchronization setup above.

My goal here is to hopefully figure out how to fix this. Lol.

Also,

FFS tries to maintain the timestamp, but is not able to, due to the used protocol or limitations in the resource's (NAS) operating system.

I'm no expert, so I may be wrong on this, but I don't believe it's a result of QNAP's operating system since it this didn't start until after I switched over to Linux from Windows.

[xCSxXenon]

this didn't start until after I switched over to Linux from Windows.

Make sure your distro is up to date also then. Also, I've seen multiple times where rolling back NAS firmware fixes these issues. With you running Linux, it's really hard to say since the implementation of NFS could be a cobbled together mess or it could be pristine. With that info, I would start reaching out in forums dedicated to your distro

[ILikeYourFace]

this didn't start until after I switched over to Linux from Windows.

Make sure your distro is up to date also then. Also, I've seen multiple times where rolling back NAS firmware fixes these issues. With you running Linux, it's really hard to say since the implementation of NFS could be a cobbled together mess or it could be pristine. With that info, I would start reaching out in forums dedicated to your distro

I don't think it's likely to be related to my distro since this started happening when I switched from Windows to Linux Mint, and now I'm on Arch and it's been happening for months. And Mint & Arch not only have distinct bases (the former is Debian-based), but Arch is rolling-release so it's pretty on top of things in terms of being up-to-date.

But I'll do some searches regardless. Who knows?

(Also, just to re-iterate, I'm using the Donation Edition, so it's the official package. :) )