New file from server is ok if local file is the same one
Bug #711389 reported by
Facundo Batista
This bug affects 6 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu One Client |
Fix Released
|
Critical
|
Facundo Batista | ||
ubuntuone-client (Ubuntu) |
Fix Released
|
High
|
Facundo Batista |
Bug Description
The same file is put in two clients; one gets first to the server, and the other receives SV_FILE_NEW.
Right now, it's a conflict (all SV_FILE_NEW goes to conflict if the file already exists).
If the local file is in LOCAL and the hash is the same than the server, it should leave the file as is (maybe cancel the upload?).
If the local file is in NONE and local hash is still nothing (the file is still not hashed), it should just set the server hash in the node (will leave it in SERVER state, and the HQ_HASH_NEW will deal with this info when it arrives).
Related branches
lp:~facundo/ubuntuone-client/fix-svfilenew-conflict
- Guillermo Gonzalez: Approve
- Lucio Torre (community): Approve
-
Diff: 293 lines (+136/-43)4 files modifiedcontrib/dump_metadata.py (+4/-3)
tests/syncdaemon/test_sync.py (+89/-0)
ubuntuone/syncdaemon/sync.py (+34/-5)
ubuntuone/syncdaemon/u1fsfsm.py (+9/-35)
description: | updated |
Changed in ubuntuone-client: | |
assignee: | Lucio Torre (lucio.torre) → Facundo Batista (facundo) |
status: | Confirmed → In Progress |
tags: | added: u1-natty-beta |
Changed in ubuntuone-client (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Facundo Batista (facundo) |
milestone: | none → ubuntu-11.04-beta-2 |
Changed in ubuntuone-client: | |
status: | In Progress → Fix Committed |
Changed in ubuntuone-client: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Also, if the file is in NONE and both hashes are the same as the received from the server (note that SV_HASH_NEW is generated by Sync no matter the hashes), it just should don't do anything.
Moving this to critical because causes a mess if you just copy an UDF from machine to machine and subscribe it in the second machine (it does LR on the volume, and sends a RescanFromScratch to the server for that volume, and it finally generates a zillion SV_HASH_NEW, which causes a zillion conflicts).