Navigation:  PeerLink Help > Running and Managing a File Collaboration Job > Runtime Job Views > Files Conflict View

Introduction

 

Files conflicts can occur for the following reasons:

 

1.Two or more users open a file at the same time before all files can be locked down by the running file collaboration job.
 

2.A file is already opened by a user when a file collaboration job is started and the file size and timestamp does not match the other target hosts.

 

3.A file is already opened by two or more users when a file collaboration job is started.

 

4.A file was modified on two or more hosts between job restarts or network outages.

 

5.A general I/O failure occurs on the Source Host after the file has been modified, but before the file is synchronized to all Target Hosts. In this case, the file will automatically be quarantined.

 

When a file conflict is detected, the file is placed in the File Conflict list (shown below) with a specific status which will determine how the conflict is resolved. The three possible file conflict statuses along with their resolution strategies are as follows:

 

 

When a file conflict occurs, the status will be set to Pending Conflict Resolution if the file has already been verified or synchronized by the initial synchronization process, otherwise the file conflict status will be set to Pending Initial Synchronization. If the conflict is a result of a fatal I/O error on the source then the file conflict status will be set to Quarantined.

 

NOTE: If a file collaboration job is stopped before a file conflict with a status of Pending Conflict Resolution is resolved, then that file will automatically be quarantined the next time the file collaboration job is started.

 

 

File Conflict and Quarantine Scenarios

 

A job is started and Initial Scan Logic is performed on a file

 

If file has never been synchronized by PeerLink and if file sizes and last modified times do not match on all collaboration hosts, or if file does not exist on one or more hosts, then the file will be synchronized based on the configured file conflict resolver, which is typically most recent last modified time.  Files that have previously been synchronized by PeerLink where just a single file’s last modified timestamp is newer than the last recorded timestamp, then that file will be synchronized to all other hosts; however, if two or more files have a more recent last modified timestamp than was last recorded timestamp, then the file will be quarantined (this is the default behavior and can be disabled by de-selecting the File Conflict Resolvers "Quarantine Offline Version Conflicts" configuration option).

 

A single user has a file opened before starting a collaboration job

 

A file conflict will be created with a status of "Pending Initial Synchronization".  After the user closes the file, if all file sizes and timestamps match then the file conflict is removed and no synchronization is performed.  However, if any file last modified times or file sizes do not match, the file will be synchronized or quarantined based on the configured file conflict resolution strategy and according to the initial scan logic detailed above. Once the file is synchronized, the file conflict will be removed.

 

Two or more users have a file open before starting a collaboration job

 

A file conflict will be created with a status of "Pending Conflict Resolution".  After the users close all files the conflict will be removed if the last modified timestamp matches on all files, otherwise if the file has never been synchronized by PeerLink then the file conflict will be updated to quarantined.  However, if the file has previously been synchronized by PeerLink, then the file will synchronized or quarantined based on the configured file conflict resolution strategy and according to the initial scan logic detailed above.

 

Two or more users open a file at the same time

 

In the rare situation when two users open a file at the same time, or in-and-around the same time and PeerLink is unable to obtain corresponding locks on target hosts before this happens (this is dependent on WAN latency and other factors), then a file conflict will be created with a status of "Pending Conflict Resolution".  After all users close the files, file lock conflict resolution will be performed as follows:

 

•If all files last modified timestamps and file sizes match, then the file conflict will be removed.

 

•If only a single file has been modified, then the file that changed is synchronized or quarantined based on the configured file conflict resolver and according to the initial scan logic detailed above.

 

•If two or more files have been modified since it was opened, then the file conflict status will be updated to quarantined.

 

 

Quarantined Files

 

Once a file is marked as Quarantined, the file will no longer participate in collaboration, and thus changes to any version of the file will not be propagated to other hosts. However, subsequent file activity on a quarantined file will be logged in the event log as a warning so you can determine who modified the file while it was quarantined. Quarantined files are saved to disk and will survive session restarts. The File Conflict list displays the time and date of the quarantine along with an error message indicating the reason for the quarantine (see below). A Quarantined File event is also logged in the Event Log and you can obtain a more detailed reason for the quarantine by analyzing the Event Log file(s). In addition, if Email Alerts and/or SNMP Notifications are configured and enabled for File Quarantines, then the appropriate message(s) will be sent.

 

 

Removing a file from Quarantine

 

You must explicitly remove a file from quarantine in order to have it participate in the collaboration session once again. To remove a file from quarantine, select the file in the File Conflict list, select the host with the correct version, and press the Release Conflict button. After doing this all hosts are checked to make sure the file is not currently locked by anybody. If no locks are found, then locks are obtained on all versions of the file and the targets that are out-of-date are synchronized with the selected source host. You may also chose to perform no action, in which case the file is removed from the File Conflict list but none of the file versions are modified; therefore if the files are not currently in-sync, then the next time the file is modified, changes will be propagated to the other hosts. If an error occurs while removing the file conflict, then the Status field in the File Conflict table is updated to reflect the error.

 

You may also select multiple files to remove from the conflict list at once.

 

 

The right-click context menu for the table contains the following actions that are unique to this particular view: