Skip to content
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

Closed
dragotin opened this issue Jun 13, 2022 · 8 comments · Fixed by #9809
Closed

Removing Sync Connection broken #9791

dragotin opened this issue Jun 13, 2022 · 8 comments · Fixed by #9809
Assignees
Labels
p1-urgent Consider a hotfix release with only that fix (ex: lose trust, money, security issue, ...) type:bug
Milestone

Comments

@dragotin
Copy link
Contributor

dragotin commented Jun 13, 2022

Describe the bug

Startpoint is: one sync connection local folder foo => / on the server and local folder bar => /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:

  1. The sync connection bar is removed, and the real sync journal gets removed. However, a new journal gets created, perhaps by an upload job that finishes after the journal was removed in the first place.
  2. The first sync connection 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)

@TheOneRing TheOneRing added this to the 3.0 milestone Jun 13, 2022
@TheOneRing TheOneRing self-assigned this Jun 13, 2022
@TheOneRing TheOneRing added p2-high Escalation, on top of current planning, release blocker p1-urgent Consider a hotfix release with only that fix (ex: lose trust, money, security issue, ...) and removed p2-high Escalation, on top of current planning, release blocker labels Jun 13, 2022
@TheOneRing TheOneRing linked a pull request Jun 21, 2022 that will close this issue
@TheOneRing TheOneRing modified the milestones: 3.0, 2.10.3 Jun 30, 2022
@gabi18 gabi18 mentioned this issue Jul 13, 2022
56 tasks
@jnweiger
Copy link
Contributor

Cannot follow the steps to reproduce with 2.10.2-rc1.1 due to #9954

@jnweiger
Copy link
Contributor

jnweiger commented Jul 25, 2022

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.

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.

@jnweiger jnweiger reopened this Jul 25, 2022
@dpapac
Copy link

dpapac commented Jul 25, 2022

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..
A force sync could not resolve the issue in my case.

@jnweiger
Copy link
Contributor

jnweiger commented Jul 25, 2022

Um, this code change looks supiciously close to the issue we see here.

client/src/gui/folder.h

Lines 106 to 110 in 19c008d

/**
* The folder is deployed by an admin
* We will hide the remove option and the disable/enable vfs option.
*/
bool isDeployed() const;

@TheOneRing please double check the initializations there: #9954 (comment)

@TheOneRing
Copy link
Contributor

You found that one issue in 2.10.2-rc1 which I mentioned and that is already fixed in 2.10.2 dailies.

@emma1382
Copy link

emma1382 commented Aug 3, 2022

tested with /home/solveigs/Applications/ownCloud-2.11.0-rc1.8255.AppImage on Manjaro-Linux :

  • still broken , cyclic Waiting Dependency :(
    ksnip_20220803-161501

@TheOneRing
Copy link
Contributor

@emma1382 the waiting status is unrelated to this issue.

@jnweiger
Copy link
Contributor

Tested with 2.11.0-daily 2022-08-04 testpilotcloud:

Confirmed fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p1-urgent Consider a hotfix release with only that fix (ex: lose trust, money, security issue, ...) type:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants