Opened at 2015-11-05T00:56:44Z
Last modified at 2016-07-21T21:32:36Z
#2568 closed defect
Magic Folder: usability issues with 'tahoe magic-folder join' — at Version 2
Reported by: | daira | Owned by: | dawuud |
---|---|---|---|
Priority: | normal | Milestone: | undecided |
Component: | code-frontend-magic-folder | Version: | 1.10.1 |
Keywords: | tahoe-magic-folder cli usability reliability review-needed | Cc: | |
Launchpad Bug: |
Description (last modified by daira)
While manually testing Magic Folder, I ran the commands for Alice to create+join a folder, and to invite Bob. Then I accidentally had Alice use Bob's invite code to join again. This didn't cause an error; it just overwrote Alice's private/magic_folder_dircap and [magic_folder]local.directory entry.
This is an easy mistake to make and could cause data loss. Alice has lost her write cap to her DMD, and there is no way to get it back (only a read cap to that directory is linked from the collective directory). Also, Alice's magic folder db will be inconsistent with the DMD that she is now using.
The above problem is easy to fix by making it an error for a client to join a magic folder when it has one already configured. (Perhaps a tahoe magic-folder leave command could be added; this would disable magic folder and also delete the magic folder db.)
A related but trickier problem is that if the invite code is used twice, then two clients will be writing to the same DMD. There's no way to enforce that an invite code is single-use, because join is a strictly local operation that has no side effects on the collective directory. This has some advantages --if you lose state but retain the invite code then you can re-join-- but is also a little error-prone.
Change History (2)
comment:1 Changed at 2015-11-05T00:57:57Z by daira
- Description modified (diff)
comment:2 Changed at 2015-11-05T00:58:44Z by daira
- Description modified (diff)
- Owner changed from daira to dawuud