Main (maybe) should not wait for HQ to be empty before sending SYS_LOCAL_RESCAN_DONE

Bug #488271 reported by Facundo Batista on 2009-11-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu One Client
Medium
Ubuntu One Foundations+ team

Bug Description

Main.py, after LR finished, explicitly waits for HQ to be empty before sending the SYS_LOCAL_RESCAN_DONE event.

This makes everything wait, and a quick analysis tells us that shouldn't be necessary. Historically, LR didn't signal properly when it finished, so maybe this "wait for HQ" was an indirect way to wait LR, and now can be removed (unless the "server rescan" operation need all the hashes of the new files to work properly).

So, we need to make a proper analysis here, and test it.

tags: added: u1-lucid
Nicola Larosa (teknico) on 2010-01-20
Changed in ubuntuone-client:
importance: Undecided → Medium
Changed in ubuntuone-client:
assignee: nobody → Ubuntu One Foundations+ team (uone-foundations)
tags: added: foundations+
tags: added: chicharra
tags: added: package
Facundo Batista (facundo) wrote :

Suppose the following scenario:

- In the previous run, the file was synched ok client-server.

- File changed locally while syncdaemon was off.

- File changed in the server while syncdaemon was off (the change is different than the local one).

Right now:

- LR finds that file changed, generates FS_FILE_CLOSE_WRITE.

- HQ hashes it, changes the node's local_hash (leaving it in LOCAL).

- ServerRescan finishes, sending a SV_HASH_NEW.

- New hash does not match node's server_hash nor local_hash, in LOCAL, -> CONFLICT.

If we do what's proposed here, have the risk of executing the following path:

- LR finds that file changed, generates FS_FILE_CLOSE_WRITE.

- ServerRescan starts, as it does not need HQ to finish to go.

- ServerRescan finishes, sending a SV_HASH_NEW.

- New hash does not match node's server_hash nor local_hash, in NONE, -> get_file, overwriting user changes.

Result: we can not do what this bug proposes. I'm marking it as invalid.

Changed in ubuntuone-client:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers