self conflict while saving the same file a lot

Bug #718924 reported by Lucio Torre on 2011-02-14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu One Client
Facundo Batista
ubuntuone-client (Ubuntu)
Facundo Batista

Bug Description

Binary package hint: ubuntuone-client

lucio@prometeo:~/tmp/udf$ apt-cache policy ubuntuone-client
  Installed: 1.5.3+r861~maverick1
  Candidate: 1.5.3+r865~maverick1
  Version table:
     1.5.3+r865~maverick1 0
        500 maverick/main amd64 Packages
 *** 1.5.3+r861~maverick1 0
        100 /var/lib/dpkg/status
     1.4.5-0ubuntu1 0
        500 maverick-updates/main amd64 Packages 0
        500 maverick/main amd64 Packages

created file a.txt, opened with vim, repeat edit then save a lot. get some conflcit files.

Related branches

Changed in ubuntuone-client (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Facundo Batista (facundo)
Lucio Torre (lucio.torre) wrote :

another user with conflicts and logs on debug

visibility: public → private
tags: added: support
Changed in ubuntuone-client:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Facundo Batista (facundo)
Facundo Batista (facundo) wrote :

Found a case of autoconflict: the Upload is cancelled after sent the EOF, and before receiving the response, so it actually changed the file in the server, but the client thinks that was cancelled, and the next Upload sends an old hash.

summary: - self conflict while editing file with vim
+ self conflict while saving the same file a lot
Facundo Batista (facundo) wrote :

There's a further problem here.

First, a PutContent(hashA->hashB) is queued, then a second one, PuContent(hashA->hashC).

The second one tries to blindly cancel the first one. If the cancellation is real, all is ok. But this bug is about what happens if the command just finished before the cancel.

The real issue is that if the first command got into the server before cancellation, the hash in the server will be hashB, and second command will fail, generating a conflict. If the second command nows that the first one was really cancelled or not is irrelevant, really.

So, the solution is:

- The second command tries to cancel the first one. It will tell if it was really cancelled or not.

- The second command *always* get the previous hash from FSM just before running, will not have it when the Upload is created.

Changed in ubuntuone-client:
status: Triaged → In Progress
Facundo Batista (facundo) wrote :

This can be easily reproduced IRL with:

import random
import sys
import time

fname = sys.argv[1]
for i in range(100):
    print "writing", i
    with open(fname, 'w') as fh:
    wait_time = random.randint(10, 5000) / 1000.0

Changed in ubuntuone-client:
status: In Progress → Fix Committed
Changed in ubuntuone-client (Ubuntu):
milestone: none → ubuntu-11.04-beta-1
tags: added: u1-natty-beta
dobey (dobey) on 2011-03-10
Changed in ubuntuone-client:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubuntuone-client - 1.5.6-0ubuntu1

ubuntuone-client (1.5.6-0ubuntu1) natty; urgency=low

  * New upstream release.
    - Remove already upstreamed patch
    - Release pathlock when command cancelled (LP: #729158)
    - syncdaemon continuously hashing (LP: #580855)
    - Self conflict when saving the same file a lot (LP: #718924)
    - SYS_QUOTA_EXCEEDED not being sent (LP: #720797)
    - The check_condition call may be too heavy (LP: #720844)
    - AQ_DOWNLOAD_CANCELLED is no more (LP: #721479)
    - SD should update a single notification (LP: #723227)
    - Two entries in Messaging menu (LP: #721525)
    - Singular form incorrect for notification (LP: #723327)
    - File names should be shown on notifications (LP: #729055)
  * Moved icon files to ubuntuone-client package (LP: #727195)
 -- Rodney Dawes <email address hidden> Wed, 09 Mar 2011 21:11:44 -0500

Changed in ubuntuone-client (Ubuntu):
status: Triaged → Fix Released
Roman Yepishev (rye) wrote :

I am removing the log files to make the bug report public.

visibility: private → public
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers