No evidence on what SeaDrive is doing

  • Environment:
  • Server: Professional Edition v. 7.1.6
  • Client: SeaDrive v. 2.0.13
  • Platform: Mostly Windows, but also Mac and Linux

Situation: When a user makes relevant changes to the directory structure of a library, it is hard for the user to understand what it is going on. Said in a different way, the user doesn’t know what the SeaDrive client is doing and how long it will take to complete. It happens that an apparently simple and quick operation like “Always keep on this device” for a small directory is launched, but the “running arrows” icon in the System Tray keep spinning without any output on the “Transfer progress” (either upload/download). During this syncing activity the user is prevented any access to the files.

The seadrive.log has been checked, but it doesn’t give enough information, in particular about what is left to do and the syntax looks hard to understand, even for a Sysadmin.

In some occasions the client looked like stuck and in the log (image attached) the following message repeats:

"The last hydrate worker has not been complted"

(verbatim, the spelling error is in the log)

and the message " cancel fetch file... " appears one per minute, probably going on for each one of the thousands of files involved in the operation.

Question 1: What is the problem?

Question 2: How can we understand if there is an error or the SeaDrive Client is working smoothly? Do exist other user-friendly ways to check the activities the SeaDrive client is carrying out exist?

Question 3: How can we monitor the activity in progress, also on the cache during creation or update activities?

The SeaDrive client is not perfect. I have highlighted various problems with SeaDrive myself. But in SeaDrive’s defence, I’ve been using SeaDrive 2.0 in production since version 2.0.1 and I have never come across the kind of problem you describe. I am not denying that you encounter these problems, but I’d assume that the problem is linked to the specific configuration/circumstances on the affected machine.

On this matter, it seems you describe the situation related to one particular machine in your question. Your fourth bullet however states: Mostly windows, but also Mac and Linux. So I must ask this question: Did you come across the stated error message on multiple devices (repeatedly) or one? If multiple devices, also on Mac and Linux machines? (The Windows client is is very different from the Mac/Linux version.)

As for your question 2. and 3.) This particular client is obviously not working smoothly. The two signals for the user to indicate SeaDrive’s activity are the systray icon and the transfer progress window. Both should, provided the client operates normally, show activity almost instantly when performing an operation in a SeaDrive folder. Also, if the client has a problem, it ought to show an overlay “!” on the systray icon.

I agree with you that the log file is not easy to read and to make sense of. The linked log file, however, cries out loud: “Problem!” It is beyond the capability of the SeaDrive client to pinpoint the specific problem. Especially in a heterogeneous environment, possibly even a BYOD environment, conflicts between the SeaDrive client and other software cannot be ruled out. In this specific case, my guess is a not-up-to-date Windows operating system or an AV programm that messes with SeaDrive.

Could you elaborate?

Hi @Dario

This log means repeated download commands are sent by the system to seadrive. Due to some reasons this may happen.

Is the canceled file one of the files the user ask to keep on this device?

Have you try to double click and open a file? Does the same problem occur?

Hi @rdb, thanks for your answer.
Trying to add some info here now.
According to the Seafile Server Infos, at the very time I am writing this we have 469 devices (cannot estimate how many sync clients vs drive clients), of which 69 connected now (that number will increase in the coming hours due to working times).
This error is present in several clients, we have reported here only one case to be as precise as possible in the reporting and tests (other clients could bring other issues too…).
All the problems we are seeing are in Windows SeaDrive 2.0.x clients. @Dario reported also Linux and Mac because all these clients are sharing the same libraries and the heterogeneous access can introduce issues as well.

Our Windows systems are mostly managed by us (at least, all these where we report issues) and are up-to-date. We use Sophos endpoint AV and have no evidence of this conflicting with SeaDrive.

However some issues with SeaDrive on some clients (e.g., see Deleted folder in a Shared with All library being re-created by SeaDrive) also affect these clients.
In particular we observed that the problems Dario reported in this topic appeared when another client (and maybe more than one) was badly behaving as described in the other ticket. So, even small delays or problems in one client affect the seafile server which, in turn, affects other clients in a domino effect.

Hello @Jonathan !
I’m the colleague of Dario who first find the log message about the “hydrate worker”.
I’ve successfully reproduced the behavior mentioned in Dario’s post that happened first to our Legal Office colleagues.
This is what I (and she) have done:

  • upload a folder in a Library via web interface with some sub-folders (~30) and files (~1500);
  • wait for the SeaDrive Client on a Windows PC to finish sync;
  • from the SeaDrive Client on the PC remove the files, keeping the folders structure;
  • from the web interface, recover the parent folder from the history, thus creating “Folder (1)” which contains the deleted files and sub-folders;
  • from the web interface, delete the original folder and rename the restored one, removing the (1) suffix.
    This triggers a very slow sync progress of the SeaDrive Client on the Windows PC. In the log file one file is processed every minute and between one file and the other 4 “hydrate worker” messages appear. One minute per files, if you have thousands of files might take an incredibly long time!

The direct answer to your questions, are:

  • no, no file has been asked to be kept permanently on the device;
  • yes, we have tried, but any operation is pending until the sync process finishes.
1 Like

Is there any way to increase the verbosity of the client log?

With seafile client’s sync algorithm, it’s normal in the use case you mentioned that the client sync the “metadata” (file list, dir list) from the server again. But we don’t know why the contents are also downloaded (unless the folder is marked as “keep on this device”). The download operation may be triggered by the system or some other software.

There are 3 more issues we have to address:

  1. Why “hydrate worker has not been completed” in the logs? It should be caused by system or 3rd party program triggered repeated download requests to SeaDrive.
  2. Why “cancel fetch file”? It should also be canceled by system or other program.
  3. Why download so slow? SeaDrive only uses 3 workers to download files. So when there are a lot of files to be downloaded, they queue up.

From a log file you sent to us, I saw that there is also an error message “Failed to find some path from repo”. This should be related to a race condition in the code. It happens when user triggers a file download when the file’s metadata (e.g. size) are also being updated by SeaDrive. SeaDrive updated file metadata when it’s changed on the server. This may cause failure in downloading files. We’ll fix it in the next version.

1 Like

@Dario @Ivan_Andrian The latest 2.0.14 may fix some of the issues mentioned here. You can have a try.

1 Like