I have "2-way syncing" set up with "delete files" enabled and there seems to be a serious problem.
Lets say I create a folder containing a file called Photo.jpg on the client.
I run a sync and both the folder and file show up on the server.
Then I delete Photo.jpg on the client side and re-sync.
The file on the server is deleted and replaced with "Photo.jpg.synDeletedFile"
Then I decide to place a file in the same folder on the client side called Photo.jpg (the same name as the previous file)
When I sync, the file does NOT show up on the server and is also deleted off the client.
Now I have no copy of my file on either the server or the client... NOT COOL
The same happens with nested folders that get deleted off the client and are renamed on the server side as .synDeletedFolder
Folders with the same name that are placed back on the client cannot be restored either.
The last modified date (LMD) of the file plays an important role in this test. I have a feeling that you are putting back the original Photo.jpg (with the same LMD) back in the folder. Syncrify will always retain the newer version of the file. Therefore, if you put the same file back with the same LMD, it think the file is supposed to be deleted from EVERY node and therefore, it gets deleted.
Try puttying a modified version of the file back (one with a newer LMD) and that will push the file across every node.
Yes, LMD seems to play a part here. It seems to work as expected if the file is changed and then put back.
The BIG problem is that files don't always get modified but may be moved around.
Syncrify's checking system will fail at this point.
Lets say I have Folder1 and Folder2
Folder1 contains File.txt
I decide to move File.txt to Folder2. After a Sync Folder1 is empty and Folder2 contains File.txt on the server.
Later I am doing some house cleaning and move File.txt back to Folder1
After a Sync, File.txt is removed from both Folder1 and Folder2 on the server and it also removed File.txt from Folder1 on the Client.
Now I have no copy anywhere of File.txt because Syncrify has deleted it.
This is not good at all. If someone is moving hundreds of files around they could lose hundreds of files after Syncing because Syncrify is not taking this situation into account. And people move files around all the time without actually modifying the files so Syncrify must do more than a LMD check.
Here is another example where only using LMD is no good...
Lets say you save a file in a folder which is 2-way synced with Syncrify.
The file now exists on the client and the server.
The file on the client gets damaged or infected with a virus.
This file gets sync'd and now exists damaged on both the client and the server.
No problem you say... you have a copy on a thumb drive and restore the file to the client.
When Syncrify syncs the files guess what...
Damaged file is newer on the server according to LMD so the damaged file says on the server and is sent to the client replacing the good recovered file.