How Multi-way Synchronization Works

When you synchronize two or more Source folders, it is known as multi-way synchronization. A Source folder is a location which qFileSync looks for new folders. qFileSync can automatically copy files from Source folders, but it will never copy files from Mirror or Merge folders. For information on one-way synchronization (to Mirror and Merge folders), click here.

I suggest you understand this section well before trusting qFileSync with your data.

The fundamental basis for a synchronization is file dates. Every file has a date stamp (the last modified date) which is updated every time you save a file. Given two copies of the same file, where one has a later date, it is often safe to overwrite the older one with the newer one. qFileSync 2.x was just this simple: figure out which copies of which files are newer and copy them. However, there are a number of ways in which this logic can fail.

For example, suppose you change two copies of the same file: qFileSync 2.x would overwrite the older file with the newer one, and you would forever lose the changes made to the other file. And suppose you delete one copy of the file. Generally you would want the other copy to be deleted as well, but qFileSync 2.x would instead tend to copy the old file to the folder it was deleted from. This typically means that the user must manually delete the file from both locations.

qFileSync 3.x, however, is smart enough to deal with these situations intelligently, by using the last synchronization date, and by introducing the concept of conflicts.

Conflicts

A conflict is a situation where it is not clear what qFileSync should do. There are two typical reasons conflicts arise:

1. Changes are made independently to two different copies of a file. For example, I often synchronize documents between my laptop and desktop computers. If I make changes to document X on both computers between syncs, it becomes a conflict.
2. qFileSync cannot tell how a situation came about; therefore, it does not know what action to take. For example, suppose that you synchronize two folders, A and B. Suppose that A but not B contains file X, and that B but not A contains file Y. Further, suppose that the date stamp on both X and Y is before the last sync. Now, there are two typical ways this situation could have arisen:
   1. X and Y existed during the last sync, but then X was deleted from B, and Y was deleted from A.
   2. Y is actually X, but it was renamed from X to Y after the last sync.

   Depending on what caused the situation, qFileSync should either delete both X and Y (situation #1), or delete X and copy Y to folder A (situation #2).

qFileSync examines folders on a file-by-file basis; for example, if you are synchronizing locations A and B, which contain a file X, the conflict and/or action to be taken regarding file X is based solely on the properties of the copies of X in A and B. qFileSync never notices any similarity or relationship between files of different names or relative paths.

Certain situations are considered conflicts, while others are not; what is and is not a conflict is defined in qFileSync.ini. This file comes with qFileSync, and defines four distinct types of conflicts. These are as follows:

• Delete/Rename Ambiguity

  This occurs when all existing files have a date before the last sync date and the file does not exist in all locations. It has two typical causes:

  1. A file was deleted from one folder (in which case it should be deleted in the other folders), or
  2. A file was renamed (in which case the file should be copied to the folders where it doesn't exist)

  This conflict arises only when smart sync mode is enabled and a last-sync date is available. The default action is to do nothing, for it may not be safe to delete the files, and there is no way for qFileSync to deal with a rename automatically. You should usually deal with this conflict manually, but if you never rename files, it may be safe to tell qFileSync to delete automatically (in the Conflict Resolution Options dialog).

• Create/Multiple-update Ambiguity

  This occurs when a file has a date after the last sync date, and the file does not exist in all locations. When using a smart sync, it has three typical causes:

  1. A new file was created
  2. An existing file was updated and then renamed, or
  3. One copy of the file was updated in one location but another copy of the file was deleted (or renamed).

  In most cases the default action, to use the newest copy of the file, is the appropriate one.

• Multiple-update conflict

  This conflict covers two kinds of cases:

  1. When multiple, differing copies of a file have a date after the last sync date, and
  2. When you are syncing three or more folders and you have a file dated before the last sync, a file dated after, and a file missing in one or more of the folders.

  If you are using smart sync mode and a last sync date is available, this conflict indicates that multiple copies of a file have changed since the last sync. Or, at least one copy was updated and at least one copy was deleted or renamed. If you are not using smart sync, or if a last sync date is not available, this conflict occurs every time two copies of a file have different dates.

  If indeed two copies of a file have been updated separately, you will need to manually reconcile the differences. You may want to set the action to "Do Nothing" in order to defer the decision of what to do until later, but be advised that this will cause the conflict type to change from "Multiple-update conflict" to "Odd dates".

• Odd dates (smart sync only)

  This conflict occurs when two or more copies of a file have different dates, each before the last sync date. Normally, after a sync has been carried out, all files have the same date, so for the dates to be different is odd. This situation can arise when

  1. The user decided to take no action on a previous sync, so the files still have different dates, or
  2. After the last sync, a file was renamed, and the new name coincided with the name of an existing file in a different location.

qFileSync's behaviour when conflicts arise is controlled by the Conflict Resolution Options dialog box.

The only situations not considered conflicts are those in which:

1. No source files exist (in other words, a file exists in a "mirror" location with no matching source files), or
2. The file is present at all source locations, copies of the file after the last sync date (if any) all match, and copies of the file before the last sync date (if any) all match. In this case the newer version of a file is copied over the older version, no questions asked.

Pitfalls

There are diverse ways in which the conflict-detection mechanism can behave unexpectedly; the main problem is the many ways in which the last sync date ("LSD") can become incorrect with respect to the files being synchronized. Here are some examples of how this can happen, and what negative effects may result from it.

• First, suppose you use two different copies of qFileSync to perform the synchronization of the same folders. One copy's version of the LSD would be updated while the other's would not.

  This might cause bogus conflicts to be detected. For example, suppose you synchronize file X on Jan 15, but the other copy of qFileSync thinks the LSD is Jan 10. Suppose the date on file X is Jan 13, and you update one copy of it on Jan 16. You will then get a multiple update conflict when you synchronize with an LSD of Jan 10, when in fact there has been only one update.

• Suppose that you're synchronizing three folders on three different laptops--A, B, and C. Suppose that sometimes only A or C is available, so you set each to "skip on error". Then, if you sync A with B but not C, the last sync will be changed even though C's files have not been synchronized.

  Suppose that A, B, and C are synchronized on Jan 10. Then, suppose that a file X was created on C on Jan 12 and A and B are synchronized on Jan 15. The LSD will be Jan 15, so the next time you synchronize C with B (or A and B), X will show up as a Delete/rename conflict. A typical user response to this conflict is to delete the remaining copies of the file, which is certainly not what should be done to a newly created file.

• Suppose that the clocks on two computers you synchronize often are out of sync by five minutes, and that you synchronize files on the computer with the later clock.

  Suppose the early clock is 2:55PM and the later clock is 3:00 PM when you synchronize. Then, suppose you create a file on the computer with the earlier clock immediately afterward, so that the date on the file is 2:58PM. Then, the next time you synchronize, the file you just created will show up as a Delete/rename conflict, even though the file is newly created.

• Suppose that an error occurs when a synchronization is partially complete and the user chooses to abort.

  In this case, the LSD is not set later even though some of the files have been synchronized. This can result in the same sorts of problems caused by the first scenario in this list.

Please e-mail me if you discover other ways in which qFileSync can behave in an unexpected way.

Table of Contents