Skip to content

Conversation

@crwood
Copy link
Member

@crwood crwood commented Mar 6, 2019

This PR contains a number of smaller changes relating to improving the adding/creation of new magic-folders and their subsequent linking into the user's "rootcap". Among them:

  • Gridsync will now use the Tahoe-LAFS web API directly when adding/creating new folders, instead of shelling out to the tahoe python CLI. This results in significantly faster initial magic-folder creates (by just under an order of magnitude in my testing) and facilitates better error-handling (since local python exceptions can be caught directly on the Gridsync-side rather than parsing the tahoe subprocess's stdout/logs for possible errors).

  • The logic surrounding tahoe daemon restarts has been improved; Gridsync will now wait until all known/queued linking events have completed before proceeding with a stop and will not restart unless at least one folder has been added/created successfully.

  • If a magic-folder fails to get added/created for any reason (e.g., due to a network disconnect event occurring immediately following an await_ready() call), Gridsync will automatically retry that operation after a 3 second delay (and after waiting, again, to ensure that the daemon has is actually "connected" before proceeding). It will only re-try once, however (and a user-facing error message will be shown in the event of a second failure).

  • In the event that a folder cannot be added/created, it will be removed immediately from the folder view/model in the UI (after displaying the error message to the user); failed folders should no longer linger or appear stuck in a "Loading..." state and/or need to be removed manually.

  • A warning/confirmation message-box will be displayed to the user in the event that they try to exit the application while a newly-added folder is still in the process of being created or if any existing folders are currently syncing.

  • A rare Qt-side crash (resulting from trying to set the mtime or size for a folder that has already been removed) has been fixed.

Closes #145

Otherwise the early return results STOPPING being set needlessly
Make all three linking/unlinking operations await on the rootcap
DeferedLock as soon as possible, that way -- in conjunction with the
previous commit -- a Tahoe.stop() will not complete until all
linking/unlinking operations have completed.
To allow the magic-folder create/join operation to be resumed or
replayed in the event that something goes wrong (e.g., a network
disconnect event, application close) before the linking operation
successfully completes.
Otherwise, debug logs can become too noisy.
This is 5-10 times faster than shelling out the python interpreter/CLI.
@crwood crwood merged commit 8c989ba into master Mar 6, 2019
@crwood crwood deleted the 145.robust-linking branch March 6, 2019 17:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make linking magic-folder caps into rootcap more robust

2 participants