SeaDrive 2.0.1 is ready for testing

Thanks @Jonathan, that is exactly why I’m looking forward to the Linux version as I was not able to use Seadrive before as all my libraries are encrypted.

I have a little weird behavior at the Cache level.

The “Free up space” option works very well when files have been downloaded from a library on the server.

However, if I add files from my computer to a library with the help of the Seadrive reader.
10go approx. I am waiting for synchronization to be ok with the server
Then I want to use The “Free up space” option, in this specific case nothing happened.
Not a single byte was released on the disk.

Hi @jacky35

I tested with smaller files (60MB) and it works. “Free up space” only works after the file is synced to the server and marked as “green tick”. Do you have a green tick status on the file? Does it work after you restart SeaDrive?


When starting automaticly Seafile (7.04 or 7.07) and Seadrive at logon :

then :

But no problem to start Seadrive “manually” after this errors.

Is it to possible to do something like this (Seafile Sync client) to preconfigure the client for automatic deployment ?



Is this version also compatible with a terminal server?
Right now i receive an error that cldapi.dll is missing.

Any idea?

This will be solved in the next version.

You have to use Windows 10 1709 or later. The new API is only available from that version on. I think there is a corresponding Windows server 2016 1709 update too.

All necessary pre-configure options for SeaDrive will be compatible. But some options don’t apply to SeaDrive (only make sense in sync client), so they won’t work.

Yes Windows 2019…

The reply is not to your question, but to another users. It’s about using SeaDrive 2.0 on Windows terminal server.

This is Microsoft’s documentation on the cloud files API.

Yes, but it is lacking information on Windows Server.

Oke, thanks. Is working.

I just had a very worrying occurrence with this beta, whereby it deleted all the files (but not directories) from the server.

In essence it looked like seadrive somehow got confused and regarded the local cache directory as the intended state and deleted all files on the server not in the local cache (in effect deleting all non-cached files).

Luckily I spotted this soon enough that I could revert to previous snapshots.

However, this is a quite a serious issue. I did take a look in the log files but couldn’t see anything illuminating as to what went wrong.


Now you scared me. I haven’t upgraded for my clients yet, but would like to hear from other people also. Is it really deleting files from the server? I believe that the local cache is different than files on the server in most cases, so the files on each server will be deleted? Can Seafile employees confirm this, pleae?

SeaDrive 2 is still in beta, so you shouldn’t be rolling it out to clients just yet. It is still use at your own risk, although most beta’s from SeaFile are fairly stable.

It had been running fine for over a month. I’m not sure exactly what went wrong. However, something clearly went amiss yesterday.


1 Like

Hello, I have installed version 2.0.1 on a freshly installed Windows 10 (V: 2004). When I start the PC, I get the message that libcrypto-1_1-x64.dll was not found. If I confirm the error message, Seadrive is terminated and if I then call this via the start menu, it starts without errors.

Many greetings

I confirm @mdovey occurence. Same thing happened to me some 2 weeks ago. Fortunately, I noticed it right away and could restore all data thanks to Seafile’s snapshots. But if it had happened in a larger organisation, the consequence would have been brutal!

I did not write earlier about it because I couldn’t rule out that I did something wrong. But apparently, I am not the only one affected.

I cannot replay the exact course of events, but this is how I recall it (Windows 10 Pro 1909, SeaDrive 2.0.1, Seafile Server 7.1.3 PE):
1.) I had two user accounts registered in SeaDrive and I switched from one to the other
2.) SeaDrive froze for a minute or two; at the end, a Windows notification informed me that SeaDrive had deleted some x-thousand files
3.) I switched back to the old user account (because I wasn’t sure what the client’s normal behavior in case of a user acccount change is)
4.) SeaDrive froze again and, again, Windows informed me that SeaDrive had deleted severel hundred files
5.) I checked on SeaHub and found the following: All libraries and folders (including subfoldes) were still there. In almost all libraries, all files had been deleted. There were one or two libraries - libraries with read-write permission - that were not at all affected, not at all.

@mdovey: Did you switch user accounts when right before your libraries got razed?

My hypothesis is that the user account change has flaws. In SeaDrive 1.0, the user account change happened pretty fast, the computer did not freeze. In SeaDrive 2.0, the CPU load soars to some 40% (Intel i5) and stays there for some minutes. (Btw, I also observe the same thing when logging an account off of SeaDrive 2.0.)

Apart from this one incident, SeaDrive has been really great! I’ve been using it daily since its release and make ~100 file transactions a day in it.

1 Like

I know SeaDrive is mostly working great. I am still installing SeaDrive version 1.x for my clients. There were some errors before, but it seems all fixed in the current installation, so I keep them running on that. We cannot afford any delete happening.

Anyway, it is a serious problem if the software is deleting files itself.