I thnk there are bugs when using Seadrive.
Seadrive client can cause mass delete files. It caused mostly when I remove the old seadrive client and install the new one.
The deleted files is randomly but I think it has relation with files that currently or just in sync.
Ourr system has been in situation of lost files many time. When reading in history, It alway have message like that: " Deleted “3a.CDR CDIO__KTD_20082020.doc” and 16 more files)
Roll back with the snapshot can recover the old ones. But (may be) lost the new update file after that time.
This error is very dangerous and it can repeat. Be careful.
Please check and resolve it.
Same problem here with SeaDrive 2.0.5
In every Library which is shared to a new user using SeaDrive this happens:
Deleted “xxx” and 19985 more files.[Details] 2020-09-08 [xxx] xxx / seadrive_2.0.5
Which version of SeaDrive do you use before you update it? SeaDrive 1.0.10 or older can have such behavior when logging out a user.
With SeaDrive 2.0, this behavior can happen when you remove a Seafile account from the client, or logout an account and choose to remove the cache. This is due to a behavior of the Windows API we use. It’s hard to completely avoid it in applications.
I confirm that I have logout and select remove cache. But this error is exists also in Seadrive 1.0.x, not only 2.0.x
And, It mean clean cache is a very dangerous action. Its must be disabled or have confirmed many time, not only and simple Yes/no confirmation.
It can caused to lost much more data quietly. Everyone must be careful with it.
We’ll look for some way to avoid it.
This just happend for us with SeaDrive v2.0.12 on Windows 10. I wasn’t cleaning SeaDrive’s cache or actually doing anything directly related to SeaDrive / our libraries. Instead I uninstalled other piece of software, OneDrive (which wasn’t in use), and then saw notifications that some thousounds of files were deleted from libraries… Maybe you at Seafile could try this to see if you can repeat the issue?
Luckily most important libraries had previous version in history so we could quickly revert deletion. But two libraries had n days of history and had no modifications during that time so after this deletion they had no previous version to revert to! I understand the logic here but maybe there could be also minimum number of snapshots to preserve? I hope we can restore these libraries from the backups without any major pain…
All in all this is quite scary problem and it should be possible to prevent this somehow. At least server side should deny mass deletions.
This literally just happened to me! WTF, thousands of files are simply GONE - and sea file web shows the last update for most folder as 51 years ago…
This is an absolute DISASTER.
Those file rest in recycle bin. You can found it in web, not via seadrive. You can recover it all.
Urgently don’t emty trash.
I’m glad it’s still in the trash, but when you’re dealing with a mass delete like this and the only way to recover the files is individually clicking “restore” on each and every file in the web browser - you will almost want to wish that they’re actually gone.
What an absurd nonsense.
But you can keep the files. Lucky than me many time.
After losing files some time, Finally I found the cause and solutions. But files of first time is much many and very important for me.
Goodluck to you.
What is the cause? What is the solution?
not found the bug. Only found that clean cache caused it. And can recover from trash is the way to resolve.
For me it was the uninstallation of OneDrive - immediately after that it deleted everything.
Unless this error, Seadrive doen’t have limit of capacity. It’s good for me.
I think this may be a bug in OneDrive. It just assumes that it’s the only one who uses the Cloud Files API and removes everything on uninstall. In Cloud files API, unregistering a virtual drive mount point will actually remove the placeholders inside it.
This is obviously NOT an issue with OneDrive - this is an issue with SeaDrive 100%.
OneDrive might have had something to do with it in some way, but clearly how SeaDrive was made/implemented/handling the issue is devastating to the end user and should never have even been remotely possible.