syncdaemon creates unnecessary conflicts
Bug #597870 reported by
Lucio Torre
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Ubuntu One Client | Status tracked in Trunk | |||||
Stable-1-2 |
Fix Committed
|
High
|
Guillermo Gonzalez | |||
Trunk |
Fix Released
|
High
|
Guillermo Gonzalez | |||
ubuntuone-client (Ubuntu) |
Confirmed
|
High
|
Unassigned |
Bug Description
When downloading directories that are being modified syncdaemon might self conflict the directory,
-------
TEST CASE:
Two Ubuntu One users, User1 & User2, are needed for this test.
1) User1 shares a folder to User2 as read-only
2) User2 accepts the share
3) User1 puts some files and folders in the shared folder
4) User1 & User2 wait for sync to finish
5) User1 deletes some files and folders created in step 3 via the web
6) User1 creates the same files and folders structure that was deleted in the step above
Expected result: Old files are deleted on User2's read-only share and then new files are created
Related branches
lp://staging/~verterok/ubuntuone-client/fix-597870
- dobey (community): Approve
- John O'Brien (community): Approve
-
Diff: 162 lines (+108/-5)2 files modifiedtests/syncdaemon/test_fsm.py (+90/-2)
ubuntuone/syncdaemon/filesystem_manager.py (+18/-3)
lp://staging/~verterok/ubuntuone-client/fix-597870-stable
- Facundo Batista (community): Approve
- John O'Brien (community): Approve
-
Diff: 162 lines (+108/-5)2 files modifiedtests/syncdaemon/test_fsm.py (+90/-2)
ubuntuone/syncdaemon/filesystem_manager.py (+18/-3)
tags: | added: chicharra |
Changed in ubuntuone-client (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Critical |
assignee: | nobody → Ubuntu One Ops+ team (ubuntuone-ops+) |
tags: | added: u1-lucid-sru |
Changed in ubuntuone-client (Ubuntu): | |
importance: | Critical → High |
description: | updated |
description: | updated |
tags: | added: testcase |
Changed in ubuntuone-client (Ubuntu): | |
assignee: | Registry Administrators (registry) → nobody |
To post a comment you must log in.
After talking with lucio, this seems to happen on read-only shares.
I hitted the issue, when getting a lot of updates to a read-only share (same share as lucio), and the cause seems to be that syncdaemon isn't able to delete a directory tree on a read-only share.
The first error in the log is:
2010-06-23 11:15:05,234 - ubuntuone. SyncDaemon. sync - ERROR - T:NONE:T 7aad9fa8- 471d-42fc- b86e-bd18609806 5e ['00f4fabb- 8390-409d- 949f-737d570e3f 07'::'567f3aaa- ed4b-47ca- 8fae-7ccae15965 78'] ''RO Share/dir/ subdir/ subsubdir' ' | Executing ACTION_FUNC 'delete_file' gave an exception: OSError(13, 'Permission denied') python2. 6/dist- packages/ ubuntuone/ syncdaemon/ fsm/fsm. py", line 137, in on_event python2. 6/dist- packages/ ubuntuone/ syncdaemon/ sync.py" , line 758, in delete_file guillermo/ .local/ share/ubuntuone /shares/ RO Share/dir/ subdir/ subsubdir/ leafdir'
Traceback (most recent call last):
File "/usr/lib/
af(event_name, parameters, *args)
File "/usr/lib/
raise e
OSError: [Errno 13] Permission denied: '/home/
After this error, the next SV_HASH_NEW event received will make the "RO Share/dir/ subdir/ subsubdir/ " go into conflict