Two-way sync does not detect/remebmer deleted files

[itside]

Hello everyone,
I'm using two-way sync to upload files from a local folder onto a remote SFTP folder. On this folder, another user is picking up the files and then deleting them. When the deletion occurs, I want the local files to be deleted as well during the next sync.

I tried "File time and size" comparison in the past, it works well if the clock of the SFTP server is the same as the local one. However, in this case, the SFTP server is not synchronized and I cannot ask them to sync it.

So, following the manual (https://freefilesync.org/manual.php?topic=comparison-settings), I tried with both "File size" and "File content" comparisons, both unsuccessfully. Every time the other user deletes one of the files I uploaded, FFS detects it as a new file and it tries to upload it again, instead of deleting it from my local folder.

Am I doing something wrong? Or maybe I didn't understand the docs correctly and what I want to do cannot be done with those two comparison types?

Thanks.
Best regards,
Luca

[xCSxXenon]

Possibly related: viewtopic.php?t=7458
Make sure the 'sync.ffs_db' file isn't being deleted in the sftp location, I think that keeps track of files for two-way and other features

[itside]

Thanks, sync.ffs_db is there, not being deleted. I took a look at the related topic, but in my case it's not a moving to a different path, just a delete. Also the folder structure is very simple, just one folder with plain files inside. Thanks.

[Plerry]

Given your reply, it seems you did not understand the impact of Zenju's reply.
Irrespective of the cause of changes (renames or just deletions), when using SFTP you can not expect any such changes will be properly detected in a two-way FFS sync.

[itside]

Hello Plerry, thanks for your reply. Maybe I continue not to understand, but nowhere in Zenju's reply, nor in FFS manual, it says that file IDs are used to keep track of files deletion. In both, only the moving is concerned. If in fact file IDs are used to keep track of deletions, the manual should be updated accordingly.

IMHO, however, it makes sense to use file IDs to keep track of moved files (and avoid copy+delete). Instead, not so much for a deletion... after all, if a file has been deleted, it has got no file ID at all anymore...

I'd like to check the code of the 2way sync, to better understand what is being stored in the sync.ffs_db, but I'm not able to find the official repository link anywhere in the FFS website... could any of you point me to it pls?

Thanks, Luca

[xCSxXenon]

https://freefilesync.org/download.php
Download the source code

[therube]

(I'm not really understanding the SFTP / .db part of things, as in why if you delete a file on the target end, it simply is not then deleted on the source, but...)

Are you able to create a Custom sync method that mimics Two Way, but without using the database (which Two Way does), would that then work?

[itside]

Hi therube,
without a DB, there is no way to know if a file existing on source doesn't exist on target because:
- it has never been transferred --> it must be uploaded from source to target;
- it was already transferred and has been deleted on target --> it must be deleted on source.
Thanks! Cheers,
Luca

[therube]

(Ah, thanks.)

[Zenju]

There is a warning message after each of your comparisons. I assume that reading it will give a clue.

[itside]

Thanks Zenju, I didn't see the alert really :-) The message says "Database file is not available: Setting default directions for synchronization.". I checked permissions on all parent folders and they're ok. In fact, if I delete the sync.ffs_db, it gets recreated after the first synchronization. But at the first comparison after the sync, it gives again that warning... Is there any detailed log to check? To understand why FFS doesn't see the DB as available?
BTW I tried also from scratch with latest version (13.3), same issue.
Thanks and regards,
Luca

[Zenju]

There should be two sync.ffs_db files, one in each left and right folder. If not, the warning comes up.

[itside]

Thanks, I think I understand now. The remote SFTP has got a root directory which is not writable, then a writable child directory where I upload the files. I believe that the issue is that FFS is trying to store the DB file in the root directory, right?
If yes, since the child dir is already specified in the connection path, shouldn't FFS store the DB inside that child dir? Or is there any way to force it?
Many thanks again. Cheers, Luca

[Zenju]

No, FFS will store the DB files in the left and right folders that are selected on the main dialog.

[itside]

Then I don't understand it. The writable directory is already selected on the main dialog, it's declared directly in the SFTP configuration:

SFTP config.png (20.92 KiB) Viewed 1308 times

I also tried to manually upload a text file renamed as sync.ffs_db just to check possible blocks on file extensions etc. but it was uploaded correctly. What else could it be? Thanks!

[itside]

Update: I managed to connect to the remote SFTP with another tool and enabled the visualization of hidden files. The sync.ffs_db is in fact created on the remote directory after synchronization. It seems that the service on the remote host is deleting not only the files I upload, but also the sync.ffs_db file... So root cause found, closing this topic. Thanks to everyone for your help!