Deleting a shared path results in orphaned SharedRepo and VirtualRepo entries that cannot be deleted

[ss23]

Replication:

1. Create a library
2. Create a folder within the library
3. Share the folder with a user
4. Delete the folder you just shared
5. Observe that shared folder is not deleted from the user's seafile client
6. Observe the entries in the database within VirtualRepo and SharedRepo still exist

This is very confusing for users and the orphaned entries do not seem to be able to be removed.

Recommendation:

• Ensure the code that deletes a path in a repository ensures all VirtualRepo and SharedRepo entries are deleted at the same time
• Implement a "cleanup" script that automatically runs on upgrade to fix these orphaned entries in old databases

[feiniks]

Hello， which version are you using?

[ss23]

Currently we are running version 8.0.4. If this is meant to be fixed in a later version, I can upgrade and test, though I didn't see anything in the changelog to indicate it would be.

[feiniks]

Hello, I can't reproduce this issue in version 8.0.8, maybe you can upgrade to version 8.0.8 to test it again.

[ss23]

@feiniks I have upgraded to Seafile 8.0.8 and the issue persists. What is the easiest way to provide more information to you? As mentioned, I can confirm that the database entries (VirtualRepo and SharedRepo) remain in the database, if that helps narrow it down.

[ss23]

I have performed further investigation and found that I cannot replicate the issue on a brand new installation. The issue persists on my existing installation, which has been upgraded for multiple years.

I am going to spend some more time looking into it, but if anyone has ideas of what could cause this to happen, that would be great.