Conflicts - "both sides have changed".... what does this mean?

[roadstar]

I just did a sync which (besides the actual new and updated files) reported this -
851 conflicts - "both sides have changed" etc.... what does this mean?
I haven't touched these particular directories or files on either my main or backup hard drive.
I have had this happen before also, but I always deselect them when doing the actual sync.

Thanks.

[xCSxXenon]

It means both copies of the files have changed since the last sync. FFS doesn't know which copy you want to keep until you tell it what to do

[roadstar]

Thanks. Yes this is logical, but the point is, I have not changed or touched those files in any way whatsoever, so how could they possibly have changed?

[xCSxXenon]

That is a good question that, unfortunately, you will have to investigate to figure out. Something changed them. What path are the files located? All in the same place? Common parent directory? What antivirus are you running?

[TAC109]

Sometimes problems like this are caused by a change to Daylight Saving Time. Click the link for more information.

[Reno]

I had this problem today and was able to fix it. Could be other things causing it too but I hope this helps some people.

First, I have to laugh at TAC109 post because today is daylight savings time but it had nothing to do with that.

I synchronized a sub folder and that created a database file. When I went back to sync the main folder I got the "Both side have changed error."

FIX: I deleted the DB file in the main folder and all sub-folders. It worked fine after that. Search for sync.ffs_db. You may need to do that on all drives?

Disclosure: I'm no expert. Today was the first time I used this program. Hopefully someone else will chime in.

[Zenju]

FIX: I deleted the DB file in the main folder and all sub-folders.

You're killing the messenger, not fixing the problem. There is no valid reason ever to manually delete the DB file.

[Reno]

You're killing the messenger, not fixing the problem. There is no valid reason ever to manually delete the DB file.

It's valid because it corrected the problem that I and many other people have had. It's also important because it makes a real mees of the user interface when hundreds or thousands of those errors pop up. That's enough to make a new user hit the uninstall button and that's not a good thing. Now that we know what's actually causing the problem, the developer may want to do something about it or let people know the workaround.

A DB file in both the main director/folder and subdirectory causes the "both sides have changed" error/flag. You only need to delete the DP file in the sub-directory. You can leave the DB file in the main directory alone and that should suffice for most people I would think.

I duplicated it again today by scanning a subdirectory and changing some files. It seems that changing files in a subdirectory makes a DB record that conflicts with the DB record that's in the main directory.

I don't see any need for me to have a DB file in the main and subdirectory and if i ever need to work with a subdirectory, I can easily delete the DB file and all is well again.

Cheers!

[Zenju]

This doesn't make any sense. Without DB file, "Two way" sync, and detection of moved files won't work. The error "both sides have changed..." is legitimate and must be fixed by the user, since the tool won't continue and risk data loss (by overwriting any side).

By deleting the DB file, you will get data loss: The file with older modification time will be overwritten, but since both sides have changed, it does contain changes, that are now lost... But at least no "warning". Yay?

[Reno]

I didn't have any data loss and this is what I found. if I sync from the main directory, that's the only place the program makes a DB file which makes sense. If I then sync from a sub-directory the program can't see the DB file above it so it makes another DB file. If I leave the DB file there and sync again from the main directory the flags come up.

Here's some more notes on reproducing it. Simply scanning a sub-directory won't cause the error. You actually have to sync something so that the DB file records it.

1. Scan a main directory that has multiple sub-directories with no DB files in them. Only one DB file will be created in the main directory and everything works fine.

2. Make a new text file in a sub-directory and sync from there. This will make a DB file in that sub-directory. Now there will be two DB files in the directory tree.

Next, scan the main directory. All the files in the sub-directory with the text files that you previously synced will be flagged "both sides have changed".

Finally, delete only the DB file in the sub-directory and scan from the main directory. No more error and no lost data.

[xCSxXenon]

I just tried to reproduce it with your steps and it worked as expected. No errors or conflicts. I agree with Zenju, the admin and developer, deleting the db file got rid of the conflict, but it doesn't solve the problem.

[Reno]

Thanks for reproducing and verifying that it works as expected without errors or conflict.

I only use the program to sync a directory and sub-directories with another computer. Deleting the DB file from the sub-director fixed the problem of it erroneously flagging both sides have changed when they did not.

I got the "both sides have changed" flag while syncing today for 2 out of 55 files in various sub-directories. But that wasn't a problem because both sides did change.

I seems the problem that I'm having is understanding what the problem is.

[Plerry]

If you first sync e.g. FolderA (left base location) with FolderB (right base location), after the sync you will a DB file in FolderA and one in FolderB.

You should not have another sync syncing e.g. base location FolderA\Subfolder1 with base location FolderB\Subfolder1.
As the base locations of this second sync are not the same as your first sync, the DB files will be written to the left- and right-side Subfolder1.
Assume you create or modify a file in the left- or right-side Subfolder1, and then run your second sync.
If you then run your first sync, both sides have changed compared to the data stored in the DB files saved in FolderA and FolderB.

The above is a self created problem, that can be easily overcome.
Also for your second sync you should define your left base location as FolderA and your right base location as FolderB, and modify your Include Filter from * (=everything) into \Subfolder1\ (=Subfolder1 and everything in it).
This second will now use and update the same DB files of your first sync; those located in FolderA and FolderB.

[Reno]

Thanks you for explaining but I really don't understand.

I think the problem that I had was fixed when I deleted the DB files in the sub-directories.

Since then, I have been scanning from the main directory which has a DB file in it and everything has been working great. Is there something that I need to be concerned about?

[Plerry]

I was just (trying to) explain how a user can create the described problem.

> Since then, I have been scanning from the main directory
Although you might not have understood my explanation, that is fully in line with my suggestion.

> the problem that I had was fixed when I deleted the DB files in the sub-directories
That action does not prevent the "both sides have changed" problem,
but (in your words) only "scanning from the main directory" should.