I’m using FreeFileSync to mirror a NAS to a local SSD. The NAS share is mounted read‑only and I never modify files directly on the NAS; all changes happen on the SSD side and then I sync back.
Right now, the directory scan/compare on the NAS is the main bottleneck. I noticed FreeFileSync maintains a synchronization database (sync.ffs_db) for moved/renamed files.
Is there any way to use this database to avoid (or drastically reduce) the full rescan on the NAS side, given that the NAS content is effectively immutable between syncs?
In other words, a mode that “trusts” the source state from the last run and only updates based on the database, instead of walking the whole NAS tree each time.
If this is not possible, would such a “trusted read‑only source” or “skip source rescan using database” mode be feasible (and useful) as a feature request?
Thanks to all in advance,
Mauro.
Use sync database to skip NAS rescan for read‑only source?
- Posts: 2
- Joined: 16 Mar 2026
- Posts: 4908
- Joined: 11 Jun 2019
No. FFS has to scan to know what differences there are. Not scanning both sides means you don't even need FFS, which means you should just use something like RoboCopy via command line. Even then, it's still 'scanning' both sides in realtime. Knowing what files are new, updated or no longer exist requires looking at every file.
The db file isn't plain text, so I am only assuming that it is using a hash of each file as a key and then its relative path for a value. If a file has a matching hash but different path, it knows to just move it instead of re-copying. The db likely doesn't hold enough information to be reliably used the way you are wanting.
To save time scanning, you can split up your syncs into smaller chunks, so there is less to scan. Or, speed up the hardware itself. Or use a file system that keeps the file table/info in a RAM/SSD cache, this wouldn't speed up file-content comparisons though.
Also, the NAS is read-only but you are also syncing the SSD back to it after working? Both can't be true
The db file isn't plain text, so I am only assuming that it is using a hash of each file as a key and then its relative path for a value. If a file has a matching hash but different path, it knows to just move it instead of re-copying. The db likely doesn't hold enough information to be reliably used the way you are wanting.
To save time scanning, you can split up your syncs into smaller chunks, so there is less to scan. Or, speed up the hardware itself. Or use a file system that keeps the file table/info in a RAM/SSD cache, this wouldn't speed up file-content comparisons though.
Also, the NAS is read-only but you are also syncing the SSD back to it after working? Both can't be true
-
- Posts: 2978
- Joined: 22 Aug 2012
> The db file isn't plain text, so I am only assuming that it is using a hash of each file as a key
As per the FFS Manual page section on "Detect Moved Files" FFS uses file-IDs, not hashes.
If a file is moved or renamed, but not modified, its file-ID stays the same. So, if a file has the same ID but is in a different location or has a different name than the name or location stored for that ID in the db-file at the end of the previous sync, FFS knows that file was moved or renamed, and may need to sync that to the opposite side of the left-right pair.
Conversely, if a file is modified, its file-ID changes. By comparing the actual/present file-ID of a file by the file-ID of that file saved in the db-file at the end of the previous sync, FFS can tell if a file has changed since the last sync, and may need to sync that to the opposite side of the left-right pair.
That is why, as per the same manual page
"Detection is not supported on file systems that don't have stable file IDs."
As per the FFS Manual page section on "Detect Moved Files" FFS uses file-IDs, not hashes.
If a file is moved or renamed, but not modified, its file-ID stays the same. So, if a file has the same ID but is in a different location or has a different name than the name or location stored for that ID in the db-file at the end of the previous sync, FFS knows that file was moved or renamed, and may need to sync that to the opposite side of the left-right pair.
Conversely, if a file is modified, its file-ID changes. By comparing the actual/present file-ID of a file by the file-ID of that file saved in the db-file at the end of the previous sync, FFS can tell if a file has changed since the last sync, and may need to sync that to the opposite side of the left-right pair.
That is why, as per the same manual page
"Detection is not supported on file systems that don't have stable file IDs."
- Posts: 2
- Joined: 16 Mar 2026
Hey guys, thanks a lot for the replies, I didn’t have notifications enabled so I didn’t see the message, but I still have this problem/question that bugs me.Also, the NAS is read-only but you are also syncing the SSD back to it after working? Both can't be true xCSxXenon, 17 Mar 2026, 18:53
Actually, the NAS is read only when I access the files trough my computer (that means I only use the nas to download files, not to upload them, as it function as a mirror of my main hard drive that I have with me all the time).
Said so, the file access is really slow cause it’s a NAS (precisely the WD My Cloud EX2 Ultra) so I would love for the program to just remember only the files that changed from the previous One Way sync so it doesn’t need to scan it again.
- Posts: 170
- Joined: 5 Jan 2024
Hi,
There is no super easy way to do a synchronization without looking at the files. You just want to make sure the app you're using does so efficiently and I don't have any idea how to compare them.
In addition to synchronization I also run a backup program called kopia. It is a lot more efficient because it runs .in the background all the time and takes a snapshot of the bits and bites that have changed since the last snapshot. If there's nothing to do it doesn't do anything and if one file has changed it changes that one file.
The difference is that being a backup program the files are in an encrypted database essentially on the server so you don't have usable readable files on both sides like you do with free file sync.
Everything has it's trade-offs. Command line sync utilities are available that might work faster but they're also more difficult to use.
Robocopy is a good example. It can be difficult in comparison to ffs because you have to micromanage it and put it in Scripts. But it is extremely fast and it picks up where it left off if you stop the transfer.
There is no super easy way to do a synchronization without looking at the files. You just want to make sure the app you're using does so efficiently and I don't have any idea how to compare them.
In addition to synchronization I also run a backup program called kopia. It is a lot more efficient because it runs .in the background all the time and takes a snapshot of the bits and bites that have changed since the last snapshot. If there's nothing to do it doesn't do anything and if one file has changed it changes that one file.
The difference is that being a backup program the files are in an encrypted database essentially on the server so you don't have usable readable files on both sides like you do with free file sync.
Everything has it's trade-offs. Command line sync utilities are available that might work faster but they're also more difficult to use.
Robocopy is a good example. It can be difficult in comparison to ffs because you have to micromanage it and put it in Scripts. But it is extremely fast and it picks up where it left off if you stop the transfer.
