Unexpected Conflict in Sync Mode

[sfusr]

I've been using FreeFileSync 4.0 for the past several years and have been impressed with its performance. A few days ago, running the same batch script (using Last Modified and Size to compare) to sync the same pair of folders generated a conflict warning which I still do not understand even after studying the documentation and other posts in this discussion group.

Background context:

I download files to Folder-A (and occasionally make changes to some of those files) which I periodically sync to Folder-B. I have used sync mode over the past few years because that was the default option when I set up the batch script. Given the nature of my workflow, in retrospect the mirror option would probably have been a better choice.

In any event, this past month I downloaded File-A to Folder-A and then synced to Folder-B. File-A was copied to Folder-B as expected. A few days later I discovered that File-A was a duplicate of another file that was residing in another sub-folder and deleted File-A because it was redundant. I have no recollection of inspecting and/or modifying the synced copy of File-A that was still sitting in Folder-B after I deleted it in Folder-A. In fact, upon syncing the two folders a few days later, I fully expected that the File-A deletion would be propagated to Folder-B automatically without any intervention necessary.

Instead, I was prompted with a conflict resolution warning which then placed me inside the GUI. A pop-up window then informed me that the file had "changed" on both sides since the last sync. This surprised me, so I inspected the Create/Modify/Access time-stamps on the copy of File-A (a PDF file) still sitting in Folder-B and observed that the most recent time-stamp (Access) corresponded precisely with the last fully completed sync operation. This only helps confirm my belief that I had not modified (or even accessed) the copy of File-A on the Folder-B side of the sync operation since the time of the last successful sync.

Question:

Fortunately I have not experienced any data loss as a result of this incident. I am concerned however that if FreeFileSync is not correctly ascertaining when files have been modified that it could be automatically overwriting what are in reality newer files with older files because of this problem (without issuing a conflict warning).

My current setup prevents me from upgrading to version 6.x in the near future. In the absence of any explanation for what is happening here and/or assurance that this issue would not have created any problems in the past, I would like to somehow inspect my sync.ffs_db files to see what I can learn from them about past decisions that FreeFileSync has made concerning which files to overwrite/delete. Unfortunately the format of that database does not appear to be particularly well documented. Even the contents of the database entries are not clearly defined anywhere as far as I can tell.

Thanks in advance for any insight that others can provide here.

[blues12]

I could not reproduce it with FFS 6.3, neither in Mirror nor in TwoWay Mode.
FFS showed no conflict when a file was deleted on one side only.

Just to wrap it up:
Folder_A: You delete File-A, but you do not touch its duplicate File-A(old).
Folder_B: Both files, File-A and File-A(old) are still there.

Now you sync Folder_A to Folder_B doing what? Two-way? Mirror? Update?
You are informed that the file has changed on both sides - what file? File-A or File-A(copy)?

[sfusr]

I could not reproduce it with FFS 6.3, neither in Mirror nor in TwoWay Mode.
FFS showed no conflict when a file was deleted on one side only.

Just to wrap it up:
Folder_A: You delete File-A, but you do not touch its duplicate File-A(old).
Folder_B: Both files, File-A and File-A(old) are still there.

Now you sync Folder_A to Folder_B doing what? Two-way? Mirror? Update?
You are informed that the file has changed on both sides - what file? File-A or File-A(copy)?

*I could not reproduce it with FFS 6.3, neither in Mirror nor in TwoWay Mode.
FFS showed no conflict when a file was deleted on one side only.*

I have also tested a simple scenario setting up two dummy folders and creating a dummy text file on one side, syncing it with the other side to copy the file over, then deleting the dummy file on the left side and syncing again in order to propagate the deletion over to the right side. Everything works as expected using version 4 in GUI mode.

*Just to wrap it up:
Folder_A: You delete File-A, but you do not touch its duplicate File-A(old).*

Correct. There are two duplicates of File A at issue here ... the one that was downloaded a long time ago into another subfolder of Folder A (which is why I deleted File-A since the older copy now makes File A redundant). There is also the duplicate of File-A that was created by FreeFileSync when I last synced Folder A (which was before I discovered that File A was redundant and proceeded to delete it). The duplicate created by FreeFileSync is indeed still there in Folder B.

When I now try to two-way sync Folder-A with Folder-B, fully expecting that the File A deletion will be propagated over to Folder B, for some unexplained reason, I am greeted with a file conflict warning instead.

*Folder_B: Both files, File-A and File-A(old) are still there.*

The only duplicate of File A in Folder B is the one created by FreeFileSync when I two-way synced the folders shortly before I deleted File A on the Folder A side after discovering that it was redundant.

*Now you sync Folder_A to Folder_B doing what? Two-way? Mirror? Update?*

All sync operations are two-way, although changes really only happen on the Folder-A side.

*You are informed that the file has changed on both sides - what file? File-A or File-A(copy)?*

I'm informed of the conflict in the version 4 GUI by a pop-up window when I move the mouse over the lightning bolt icon between the two columns (left side is Folder A; right side is Folder B) that "both sides have changed" since the last sync. FFS is correct that the left-hand side (Folder A) has changed since the last sync (because I deleted File A) and the GUI appropriately shows a blank row there. The right-hand side (Folder B) still shows the copy of file A sitting there that was created during the last completed sync operation.

What is not clear is why FFS believes that this Folder-B side copy of File-A (which is just a non-editable PDF file) has changed since the last completed sync when its Create/Modify/Access time-stamps all pre-date the writing of the last sync.ffs_db file in Folder B.

[blues12]

>>...why FFS believes that this Folder-B side ... has changed

Baffles me too. No clue what's going on here.
Why can't you update to a newer version?

[sfusr]

I'm going to try the latest portable version and see if it throws up the same conflict warning message. (For safety, I'll use copies of the sync.ffs_db database because I read somewhere that more recent versions of FFS convert these files to more current formats.)

Nevertheless, what would be really helpful here is to learn more about the kind of file metadata that sync.ffs_db is recording after each 2-say sync and to have a more precise description of the step-by-step algorithm that FFS employs to determine whether or not a file has changed since the last 2-way sync operation.

Is this already available somewhere?