-
Notifications
You must be signed in to change notification settings - Fork 25
145.robust linking #160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
145.robust linking #160
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Qt's mime data handler appends a trailing slash to paths on macOs, for whatever reason, which causes os.path.basename() to return an empty string. Wrapping paths in os.path.realpath() removes the trailing slash (in addition to its primary purpose of resolving symlinks).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
tahoepython 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 thetahoesubprocess's stdout/logs for possible errors).The logic surrounding
tahoedaemon restarts has been improved; Gridsync will now wait until all known/queued linking events have completed before proceeding with astopand 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