I haven’t opened up the oDrive Sync client in at least a couple of months since it took over 4hrs last time I opened it to figure out where it was and where to continue.
After leaving it running for a few hours but pausing sync right away it now shows 2813 in “Waiting” and 2803 files in the “Trash Bin” where all 2803 files in the “Trash Bin” are also part of the 2813 in “Waiting”.
Maybe I don’t understand what the Trash Bin is for, but this doesn’t look right to me.
Hi Till,
Do you have auto trash enabled?
Since you paused sync, it is possible that there are some transitional states that can’t be reconciled because sync is stopped.
What version of the client is currently running?
Hi Tony.
Auto Empty Trash is disabled.
It says “prod 5686” (btw, is there some sort of in-client update feature, so it finds updates itself and downloads/installs them without having to do all that manually?)
what’s the best/safest thing for me to do now? unpause sync and let it do its thing?
thanks for your help, Tony!
Hi,
Yes there is an auto-updater, which it looks like you got.
The trash and waiting duplicates could possibly have been triggered by moves while the client was not running. In that case it has detected that files that were previously in a location are now gone and it has picked up files in a new location. Do the files look familiar?
When you unpause sync it will let odrive figure out what to do with the changes it has detected. It is possible that the pausing that time lag could prevent the move optimization from happening, which would result in a “delete” (to odrive trash), and an upload from the new location.
Every version update, so far, I’ve had to first find, download, and install manually, including this last one, which I did prior to getting back into seeing where we are with oDrive…it has never alerted me of an updated version and offered to update itself…would that be the behavior to expect?
I went to a business meeting an hour away earlier and before i left I decided to just turn Automatic Sync back on and let it do its thing while I was away for a few hours…now, about 5hrs later, it has still not started to sync, and appears to still be figuring out what my sync folders are up to.
I should add that my synced folder have a ridiculous amount of files in them…as a timelapse photographer, my “Timelapses” folder in “Images” alone contains in excess of 500,000 photos…some of my folders contain sparsebundles of computer backups which also contains 100,000’s of files, and list goes on and on…I am not that surprised that oDrive takes in excess of 6-8hrs before it does anything after being started back up, but I am also thinking that I might have to devise a new strategy about how to effectively use oDrive…I do have to shut it down at times, but waiting 6-8hrs every time I want to start it back up is also not really an efficient way of doing things.
I probably don’t use it correctly and need to learn about un-syncing folders that have been synced, just so it won’t re-scan them every time I start it back up? Any other suggestions as to how I could use this excellent sync client in a more effective way? I am still waiting for it to upload even a single file since I first started it up some 7hrs ago…it’s still scanning folders in my backup set.
@Till_Krueger: I’ve noticed the same behavior when odrive is started on a system containing a large number of files and where odrive has not run for a long time. Other desktop cloud clients do the same thing, but not for as long. For example, I restarted a legacy Win 12 R2 server yesterday afternoon and odrive still had not uploaded a thing in 16 hours. The cloud storage was on Dropbox for Biz so I quit odrive and started DB. The DB client churned for 3 hours before uploading the handful of modified files.
Yeah, the initial scan is pretty heavy.You have to remember that the client needs to scan not only the local structure, but it has to ask the cloud for the contents of each folder. I mentioned this in another post, but 3rd party API consumers tend to get more heavily limited on the APIs than the native client (it makes sense that they would give themselves preferential treatment). It is possible that your massive structures are getting rate limited, to a degree,which will defintiely prolong operations.
Structure size is probably the largest factor in scan op overhead. It’s why we invented unsync 
Our recommendation is to unsync synced content in structures that you do not need to access often. Our forthcoming backup feature will also reduce this type of overhead because it will be one-way sync, which means we don’t have to worry about scanning the remote locations for changes, which is the largest time sink in this type of scenario.
That will be a welcome feature indeed! Looking forward to it with two questions:
Will the backup/one way mode support encryption? Less appealing if not.
How can deletions be managed? I’m thinking of occasional maintenance cycles where the cloud contents can be trimmed to match local data. Particularly critical if encrypted shares are supported as there is no feasible way to match cloud to local content without odrive.