I've been facing multiple oDrive2 issues recently

I don’t know what’s changed… But for the past few weeks too many things haven’t been working properly…

  1. Attempt to open the sync agent leads to the following window being displayed for hours, sometimes indefinitely:
    Sometimes the sync eventually manages to connect (after hours of trying), sometimes it doesn’t
  2. Whenever oDrive2 is running, any attempt to right-click a file in Explorer causes the explorer to freeze for many minutes, sometimes indefinitely. This prevents files from being renamed, their properties from being viewed etc.
  3. All attempts to upgrade badges for sync consistently fail:

I’ve tried reinstalling the agent multiple times. Nothing helps.

This, by the way, brings me to another issue / question:
4) Whenever I reinstall the agent, I then need to manually re-create all the syncs with the files and directories that had existed on the disk prior to reinstalling the agent. This is tricky, complicated and in my case also takes days, as there are a couple of terabytes of synced data. I don’t know if the agent merely compares the contents or maybe does something else, but in any case the price of reinstalling the agent is too high. Isn’t there a more elegant solution to this problem than just manually doing everything all over again and waiting?

I don’t know what to do and could really use some help…

Hi @alexeybgs,
There are a few components that are involved with the sync client. #1 and #2 above seems to indicate that the client UI components cannot communicate with the underlying sync daemon for some reason. It is odd that it will eventually work, but only after hours of waiting. This could indicate that the sync daemon is very busy processing something, or that something is blocking communication.

How much data (in terms of number of files and folders) is the odrive2 client tracking currently?

The sync badging error can happen if the client isn’t able to release the previous version of the badging to upgrade it. That issue is more expected and won’t cause a problem with sync behavior, but could affect the overlays you see in explorer.

Thanks, @Tony
Right now only a tiny portion of my cloud data is synced with the local disk. It’s 15.6GB in 124599 files. No massive changes have recently occurred. I only change a couple of files on a daily basis. Is there a way to find out what’s going on? I was able to run the shell, are there any useful commands I could run?

Hi @alexeybgs,
I would be curious how the shell behaves when you are seeing the “connecting with odrive Deamon” message. Is the shell able to connect and communicate?

If so, what do the following commands show?

  • sync status
  • sync log
  • sync watch

sync status will be the most telling, but the others will show if there is currently activity.


It took the shell a few minutes to connect, but it eventually succeeded while the sync was still trying, with no success. The output looks like this:



I wonder if the problems have to do with the fact that my laptop is a corporate one, managed by the corporate IT. Maybe odrive somehow conflicts with one of the services on my PC…

Hi @alexeybgs,
Thanks for the additional info.

Do the ‘sync status’ numbers change at all if you continue to make that call to the daemon? I’m just curious if there is still processing going on.

During the time where you are unable to connect, do you notice any spikes in CPU?

When the shell was unable to connect for a few minutes, was it kicking back an error or just “hanging”?

Do you run odrive2 on any personal systems, and, if so, do they exhibit the same behavior against the same data set?

I am trying to see if I can reproduce this behavior here, but so far I haven’t been successful…

The sync status numbers don’t really change, which is natural as the contents haven’t changed for days. The shell opens quickly, but “sync status” was hanging for about 40 minutes before it produced the results. The next time I tried (a few minutes later), the command took just a few seconds to run. The numbers were exactly the same.

While sync monitor is attempting to connect to the daemon, the CPU consumption is very high:

Closing the sync monitor doesn’t have a pronounced effect, but quitting odrive2 altogether causes the CPU utilization to drop significantly:

Currently, this is the only system I have that’s running odrive2, so I don’t have a reference to compare this behavior to…

Hi @alexeybgs,
I’ve been spending some time trying to mimic your setup and testing with a structure of about 120K objects. Unfortunately I am not seeing the same issue as you are with the very long wait time to get the UI to communicate with the sync daemon. My testing shows about a 10 second wait for things to come up.

I will message you a test build to try, which changes the initialization order of the daemon a bit and may help, but you may have been on to something when you speculated that something in the environment was causing some interference/conflict of some sort.