Suggestion about having unique sync.ffs_db

[pnachtwey]

I have had one disaster using FFS. I am pretty sure it happened because of 3 reasons.
1. I was new to FFS and is much different than robocopy and synchronize it.
2. FFS WILL DELETE FILES in two-way and update mode if it sees files in the source are not in the destination. Robocopy and Synchronize it will not do this unless you specify /PURGE or /MIR on the roboy copy and chose backup mode on Synchronize it.
3. FFS uses the same name for ALL sync.ffs_db

I have an old Drobo5N NAS, a newer Synology NAS and a 8TB USB attached to my Synology router.
I back up to all of them and try to keep them synchronized.
I also used Synchronize It before finding out about FFS. The problem occurs when a sync.ffs_db gets copied over because it has the same name as another sync.ffs_db so now it is no longer valid. I think this is what happened when my disaster occurred. Fortunately most files were backed up.

So now I am wiser and don't copy the sync.ffs_db. This seems to be working but the fact that all the data base files have the same name is a disaster waiting too happen. It would be better if the sync.ffs_db files had an identification number number attached like sync0123.ffs_db so they are unique. The task would need to keep track of what data base to use. This way data bases won't get copied over when using other copy methods. I can backup to a NAS from 4 different computers in my house.

I see there is an option to check if files have been "moved" but often it is grayed out so it can't be changed.
I understand that the FFS data base makes updating directories faster.

I am still having problems with the CopyFileEx making *ffs_tmp files that can't be written over by FFS.

Things are getting better now that I know what to watch for.

[Zenju]

It's not possible to have data loss caused by a somehow broken/corrupted sync.ffs_db file. When a sync.ffs_db file is copied so that both source and target have a bitwise identical sync.ffs_db file FFS will behave just like on it's first sync of these two folders (existing on one side? => copy to other, file older? => copy over newer). From the second sync on operation will be back to normal.

[xCSxXenon]

Also, two-way and update will definitely not delete files from target, for two reasons:
1) Two-way had no target
2) 'Update' is explicitly set up to never delete
Your configuration must have been incorrect

[pnachtwey]

FFS two-way synchronizations acts like it has a/purge or /mir function like in robocopy or --delete in rsync by default. If the left hand side doesn't have a file and the right hand side does, the right hand side is marked for deletion. I know about it now. It just caught me by surprise once.
My solution is to use update then switch the left and right hand sides. This is similar to what I must do with robocopy or rsync where I must make scripts that copy both ways. FFS's big advantage is the user interface and the multi thread capability.

[Plerry]

@pnachtwey
Instead of using two different sync variants sequentially,
try out creating your own Custom sync variant,

[xCSxXenon]

FFS two-way synchronizations acts like it has a/purge or /mir function like in robocopy or --delete in rsync by default. If the left hand side doesn't have a file and the right hand side does, the right hand side is marked for deletion. I know about it now. It just caught me by surprise once.
My solution is to use update then switch the left and right hand sides. This is similar to what I must do with robocopy or rsync where I must make scripts that copy both ways. FFS's big advantage is the user interface and the multi thread capability.

This is not true. Two-way will delete a file from one side if it was deleted from the other, non-directional.

[pnachtwey]

This is not true. Two-way will delete a file from one side if it was deleted from the other, non-directional.

Yes, I noticed that now. It will only delete files on the right side ( dst ) that are not on the right side ( src )
This is where I got into trouble. I have several PCs ( Windoze, Mac, and linux ) that I save to a NAS. Not all the PCs have the same thing so sometimes I used FFS to synchronize to the NAS The problem arises when there is something on the NAS that isn't on that particular PC. The files on the NAS got deleted. My cure is that I never use the synchronize feature of FFS for doing bulk synchronizations, only on targeted directories where I know both the PC and the NAS have similar files.

What makes FFS shine compared to other synchronizing tools is the interface and it works pretty much the same on all machines. I use:
rsync, FreeFileSync and timeshift for linux
Syncrhonize It, robocopy, FreeFileSync for Windoze
Chronosync, FreeFileSync and TimeMachine for Mac
On my Mac I use Chronosync for bulk backups and FreeFileSync for comparing and synchronizing directories.
The synchronize feature of Synchronize it does not delete files off the destination.

What I like about rsync is that I can make an exclude file. This is necessary to keep from copying the FFS data base files. It took me a while to discover I could have default excludes in FFS.