-
Notifications
You must be signed in to change notification settings - Fork 663
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
Removing Sync Connection broken #9791
Comments
Cannot follow the steps to reproduce with 2.10.2-rc1.1 due to #9954 |
I am afraid, it also happens with a single sync connection: #9954 (comment) @dragotin Did you try a force sync to resolve the 'eternal wait'? -- In my case it helped. |
On Ubuntu 20.04 Desktop-Client Version: 2.10.1: I could reproduce this behavior, a previously synced folder and the sync status won't change.. |
Um, this code change looks supiciously close to the issue we see here. Lines 106 to 110 in 19c008d
@TheOneRing please double check the initializations there: #9954 (comment) |
You found that one issue in 2.10.2-rc1 which I mentioned and that is already fixed in 2.10.2 dailies. |
@emma1382 the waiting status is unrelated to this issue. |
Tested with 2.11.0-daily 2022-08-04 testpilotcloud:
Confirmed fixed. |
Describe the bug
Startpoint is: one sync connection local folder
foo => /
on the server and local folderbar => /bar
. Note that the second sync connection syncs into a sub folder of the the first one, which is bad, but anyway...If bar is syncing (ie. after it was just added and the first sync is happening) and the sync connection is removed through the menu item, strange things happen:
foo
went into the "wait" state because through bar's sync activity, it got changed (remember bar syncs into a sub folder of foo) and wants to sync. Once bar went away, foo could actually start to sync. The error is that that does not happen. The remaining sync connection remains in wait state (forever?).Expected behavior
Remove foo and just start to sync bar.
? Remove bar and just start to sync foo?
I am not sure if the cross-sync-setup is really needed to reproduce that, or if normal sync connection would show that fail as well.
Client version number
Current master (3.0.0-git)
The text was updated successfully, but these errors were encountered: