Uploaded image for project: 'Nuxeo Drive '
  1. Nuxeo Drive
  2. NXDRIVE-382

Invalid conflict resolution when choosing the Local file, if the Remote file has been renamed before

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0626
    • Fix Version/s: 4.4.2
    • Component/s: Synchronizer
    • Release Notes Summary:
      Fixed a long-standing sync bug
    • Release Notes Description:
      Hide

      Conflicts are now even more precisely managed.
      The old bug was:

      • A file is in conflict (edited locally and remotely).
      • That file has been renamed remotely, changing its file name locally.
      • When resolving the conflict: the use chose to use its local version of the file.

      The fix provide this expected behavior;

      • The remote file is replaced with the local one.
      • the remote file keeps its metadata.
      Show
      Conflicts are now even more precisely managed. The old bug was: A file is in conflict (edited locally and remotely). That file has been renamed remotely, changing its file name locally. When resolving the conflict: the use chose to use its local version of the file. The fix provide this expected behavior; The remote file is replaced with the local one. the remote file keeps its metadata.
    • Tags:
    • Sprint:
      nxDrive 11.1.30, nxDrive 11.1.31
    • Story Points:
      2

      Description

      Nuxeo Drive has an incorrect way to resolve the conflict when this scenario played:

      1. Set up a Drive sync'd folder containing at least one file
      2. Suspend the client synchronization
      3. Edit the server-side document so that its filename is changed
      4. Edit the client-side file
      5. Resume the synchronization
      6. The conflict is detected, resolve it by choosing to keep the local file

      • Expected behavior: The server document has its file replaced with the client file, with the client's filename, and otherwise retains the server file's metadata.
      • Observed behavior: The server document is untouched. The client document is uploaded as a brand new File. Also, Nuxeo Drive is unaware the the server document still exists (its file is missing from the client folders).

      The real issue with this behavior is that the new file has none of the property values it held before the conflict (custom schemas, etc.), making it difficult to fix things manually afterwards.

      I looked a bit into the client behavior, and suggest one of the two following fixes:

      1. Split the resolution in two steps: renaming the server file to the new client name, then uploading the file.
      2. Replace or improve the "batch/upload" call to have something aware of the document UUID we're targeting, instead of relying on the file name.

      (Note: Tested only with a Nuxeo 5.6 server)

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 days
                2d

                  PagerDuty

                  Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.