(Please excuse my English)
Some network drives and cloud drives are readonly or prohibit storing sync.ffs_db and sync.ffs_lock in the root directory.
But I don't know how to save sync.ffs_db and sync.ffs_lock to another place. Please let me know how.
It will be very helpful if the path(and name) of sync.ffs_db and sync.ffs_lock can be specified in each freefilesync job setting file(.ffs_gui and .ffs_batch).
Can I save sync.ffs_db and sync.ffs_lock to another place?
- Posts: 3
- Joined: 25 Apr 2025
-
- Posts: 2946
- Joined: 22 Aug 2012
- Posts: 3
- Joined: 25 Apr 2025
I understand the below.
"The sync.ffs_db-file (just like the sync.ffs_lock-file, if used) must be in the root of the left and right base-location, because syncs may be run on/by multiple computers to/from one and the same base-location."
However, it’s not that helpful if the sync.ffs_db and the sync.ffs_lock cannot be written.
When running FreeFileSync for the read-only remote directory, I can see lots of error logs on illegal write attempts for the remote directory.
If a program is only producing lots of errors without any countermeasures despite understanding the cause of the errors, how can we say that the program is a high-quality program?
Of course, it's important to think about cases where multiple FreeFileSync instances are running simultaneously for the same location. But It's also important to think that only one FreeFileSync is running for the location in most cases. Convenience for most cases should be considered as a priority.
"The sync.ffs_db-file (just like the sync.ffs_lock-file, if used) must be in the root of the left and right base-location, because syncs may be run on/by multiple computers to/from one and the same base-location."
However, it’s not that helpful if the sync.ffs_db and the sync.ffs_lock cannot be written.
When running FreeFileSync for the read-only remote directory, I can see lots of error logs on illegal write attempts for the remote directory.
If a program is only producing lots of errors without any countermeasures despite understanding the cause of the errors, how can we say that the program is a high-quality program?
Of course, it's important to think about cases where multiple FreeFileSync instances are running simultaneously for the same location. But It's also important to think that only one FreeFileSync is running for the location in most cases. Convenience for most cases should be considered as a priority.
-
- Posts: 2946
- Joined: 22 Aug 2012
It is your choice to checkmark "Use database to detect changes" in the Synchronization Settings (F8).
You don't have to. If you don't, no sync.ffs_db files are written.
Similarly, you can disable the use of sync.ffs_lock files by setting the LockDirectoriesDuringSync flag to false.
And obviously there is still the suggested workaround referred to in my previous reply.
So, for your convenience, the choice is yours ...
You don't have to. If you don't, no sync.ffs_db files are written.
Similarly, you can disable the use of sync.ffs_lock files by setting the LockDirectoriesDuringSync flag to false.
And obviously there is still the suggested workaround referred to in my previous reply.
So, for your convenience, the choice is yours ...
-
- Posts: 47
- Joined: 16 Feb 2019
is there an advantage of using sync.ffs_db files then?
- Posts: 3
- Joined: 25 Apr 2025
The biggest advantage of FreesFileSync compared to other sync programs (rsync or rclone) is its sophisticated detection of moved files, and this advantage comes from the sync.ffs_db file, as far as I know. So, if I disable writing sync.ffs_db files, wouldn't the biggest advantage of FreeFileSync be lost?
-
- Posts: 2946
- Joined: 22 Aug 2012
> So, if I disable writing sync.ffs_db files, wouldn't the biggest advantage of FreeFileSync be lost?
Whether the use/availability of a database is FFS's biggest advantage likely depends on your use case.
Personally I never use it, for similar reasons as you started this discussion (the source of my sync is almost always read-only for the user under which credentials the FFS is run). But I don't miss the advantages of using the database, because I hardly ever re-organize or rename items in my sync source (nor need to). Therefore I even never tried/used the workaround referred to in my previous replies.
In my perception, the biggest potential advantage of the use of the database by FFS is that it saves time:
Items that are moved or renamed in one side, are also moved or renamed at the other side, instead of deleting the items under their old name or in their old location, and copying those files over again under their new name or in their new location.
For these cases, the end-result is the same; it just saves time.
Whether the use/availability of a database is FFS's biggest advantage likely depends on your use case.
Personally I never use it, for similar reasons as you started this discussion (the source of my sync is almost always read-only for the user under which credentials the FFS is run). But I don't miss the advantages of using the database, because I hardly ever re-organize or rename items in my sync source (nor need to). Therefore I even never tried/used the workaround referred to in my previous replies.
In my perception, the biggest potential advantage of the use of the database by FFS is that it saves time:
Items that are moved or renamed in one side, are also moved or renamed at the other side, instead of deleting the items under their old name or in their old location, and copying those files over again under their new name or in their new location.
For these cases, the end-result is the same; it just saves time.
