Sync cannot be removed after a share has been stopped

[jens-br]

Steps to reproduce this error:

1. Have a library shared with your account.
2. Sync it locally.
3. Let the other person remove the share (possibly while the client is not active, not checked yet).
4. Check your client -> Errors are thrown regularly that the server "has rejected the connection". However, the share can still not be removed in the client, because the client seems to show only libraries that can be found online...
   [07/24/24 14:31:58] sync-mgr.c(618): Repo 'test' sync state transition from uploading to 'error': 'Permission denied on server'.

Could you fix this nasty bug short-term? Or at least provide how to edit the config files accordingly to remove the sync? Deleting the folder data in .seafile-data/index did not help.
As a user, I would simply expect that this case would be handled similarly to the synchronization of libraries that were not found on the server. I guess it would be more intuitive and easy to use if the 403 responses would be handled the same way.

[killing]

Currently these permission errors are only retried for 3 times and the library will not be synced until the next restart. Actually it shouldn't affect the use.

[jens-br]

Many thanks for you for your response and for checking it! :-)

Within the first sentence, there is the problem for the usage:
On every restart, the client tries to sync the library (i.e. every time I restart the computer).
That fails and every time, my client warns me (with the icon containing the exclamation mark in the task bar) that there are sync errors.
Then, I have to check if there are real sync errors or if there is damage to the library (which happens sometimes).
So on every computer startup, I need to separately open the Seafile client and to check if there are real errors or not.
This is quite cumbersome, since it delays the workflow.
The icon does not distinguish if there are real problems - or if it is just the failed sync of that library which I do not have access to anymore.
It is crucial that a user can rely on a warning sign.
Therefore, the current cluttering of the warning logs is quite counter-productive, especially for professional usage.

Due to the workflow and usage problems described in this post, I would therefore like to ask you to fix this bug.
Many thanks in advance!