# Resolving conflicts in async

Description

Aspera Sync (async) allows you to synchronize a local and remote directory so that they contain the same content.

At times, async sessions fail because of conflicts. Conflicts can occur when the same files have been modified on both the local and remote directory, making it impossible for async to determine which version to use.

In this case, async leaves the files on both ends intact, and leaves it up to you the user to resolve manually.

Methods of resolution

There are a few methods you can use to resolve file conflicts.

Method 1: Modify a conflict file on both sides

This method involves comparing the conflict files on both systems and modifying them until there is no conflict.

Details

While on one system, move the remote conflict file to a separate directory on the local system.

You can use a utility like diff to compare the two conflict files line by line:

# diff /path/to/conflict_file /path/to/other/conflict_file

Using this information, make the necessary changes on the local conflict file and the remote conflict file so they no longer differ.

To verify that the two files no longer have a conflict, check the checksums on both files. You can see the checksum of a file with the following command:

Linux
# md5sum /path/to/file

Mac
# md5 /path/to/file

Windows
CertUtil -hashfile C:\path\to\file MD5

If the checksums match you know that the files are the same on both ends, so you can run the async session again and the conflict will be removed.

Method 2: Deleting a conflict file on one side

This method involves choosing one system to delete a conflict file on, then running the async session again. This will remove the conflict and synchronize the two systems to have the file that was not deleted.

Example

Say we have a system A and a system B. On both systems we have the following directory and files we’d like to keep synchronized:

My_documents
---Document1
---Document2
---Document3

You work on system A and make changes to Document2, and a colleague on system B makes changes to Document2.

You then run an async session to synchronize your changes to system B, but since changes were made to Document2 on both ends, you run into the following error:

async -N my_bidi_sync -d /my_documents -r colleague@B:/home/my_documents -w pass -K bidi
/              SYNCHRONIZED
/Document1     SYNCHRONIZED
/Document2     CONFLICT
/Document3     SYNCHRONIZED

Using this error information you know that there is a conflict on Document2. Deleting this file on one end would remove the conflict.

If you have access to system B, you can check Document2 on both ends, and decide from there which version of the file to keep. If you do not have access to system B, you may need to coordinate with those who do have access to system B in order to determine which version to delete.

In this example, say you have access to both systems. On system B you see that your colleague added obsolete information to Document2, and that the information you added is more up to date. You decide to delete the file on system B so that the more up to date file on system A is synchronized across both systems.

Once you have deleted Document2 on one end, you run the async command again so that both systems have the correct version of the file:

async -N my_bidi_sync -d /my_documents -r colleague@B:/home/my_documents -w pass -K bidi
/              SYNCHRONIZED
/Document1     SYNCHRONIZED
/Document2     SYNCHRONIZED
/Document3     SYNCHRONIZED

Method 3: Renaming a conflict file on one side

This method involves choosing one system to rename a conflict file on, then running the async session again. This will remove the conflict and synchronize the two systems so they both contain the two versions of the file.

Example

Say we have a system A and a system B. On both systems we have the following directory and files we’d like to keep synchronized:

MovieClips
---Clip1.mov
---Clip2.mov
---Clip3.mov

You make changes to Clip1.mov on system A, and a colleague on system B modifies Clip1.mov

You then run an async session to synchronize your changes to system B, but since changes were made to Clip1.mov on both ends, you run into the following error:

async -N my_bidi_sync -d /MovieClips -r colleague@B:/home/my_documents -w pass -K bidi
/             SYNCHRONIZED
/Clip1.mov    CONFLICT
/Clip2.mov    SYNCHRONIZED
/Clip3.mov    SYNCHRONIZED

Using this error information you know that there is a conflict on Clip1.mov. Renaming this file on one end would remove the conflict.

This may make sense if you need to retain information from both modified files, and if you eventually intend to merge the changes between the two files.

On system A, you therefore decide to rename the file you modified to Clip1_sysA.mov. You then run the async session again:

async -N my_bidi_sync -d /MovieClips -r colleague@B:/home/my_documents -w pass -K bidi
/             SYNCHRONIZED
/Clip1.mov    SYNCHRONIZED
/Clip2.mov    SYNCHRONIZED
/Clip3.mov    SYNCHRONIZED

On both system A and system B you now have the files Clip1.mov and Clip1_sysA.mov.