Thanks for this. Fixed the issue for me as soon as I emptied my odrive trash after killing and restarting the app. It seems to be a problem when too many items accumulate (which can happen when you have trash set to empty - never as I did) and odrive cannot enumerate all the items for displaying in the menu, crashing the contextual menu.
2 Likes
Thanks for the report @pavila. We plan to address this behavior in an upcoming release, but it is good to know that the issue can be dealt with this way, for now.
2 Likes
Hi.
I am also seeing this crash behaviour of the task menu. My issue is a large initial sync that cause it to stop syncing. However the weird thing is that before the crash it shows network usage of 1-4MB/s upload as that is my bandwidth, but when it crashes, it shows about 4 MB/s upload but 2-3MB/s upload to odrive.exe and only 1 or so MB/s upload to Google Drive. Google drive also doesn’t seem to report any new files for a while. I have currently about 1277 pending changes which will probably go out to 10K+. These are all loads of small files. I am trying the previous commands above to see if i can see any crash information if it does crash again .
Hi @shane,
Can you clarify the upload speed segmentation? I don’t quite understand the split you are seeing.
For very large uploads it can hit some bumps, so just keep an eye on things. Upload behavior will be improved in our upcoming major release, but it still still several weeks out.
Hi Tony,
Uncertain what you mean by speed segmentation. But here is some info that may help. Also my computer did a reboot last night and this is just from the autostart function of odrive. The menu option of the task trak icon worked for a while with the last reading of 6000 waiting files before i can’t access it again. It looks like it is still working in the background though.
I am on a 100/40 mbps VDSL connection. My network activity via process monitor is as follows:
under Processes with Activities section
odriveapp.exe Send (B/sec) = 5,087,250 Receive (B/sec) 199,778 Total (B/sec) = 5,287,028
odrive.exe Send (B/sec) = 41 Received (B/Sec) 2,618,808 Total (B/sec) = 2,618,849
under Network Activity (address DESKTOP is local pc name, syd09s is google server)
IMAGE ADDRESS SEND (B/SEC) RECEIVED (B/SEC)
odriveapp.exe DESKTOP 2,618,734 183
drive.exe DESKTOP 41 2,618,808
odriveapp.exe syd09s 2,304,714 176,078
odriveapp.exe syd09s 681,709 84,240
odriveapp.exe syd09s 643,140 20,304
output from the CLI Status function:
C:\Users\shane>powershell -command “& {$comm_bin=”$HOME.odrive\common\bin";$o_cli_bin="$comm_bin\odrive.exe";$(& “$o_cli_bin” status);}"
odrive Make Cloud Storage THE WAY IT SHOULD BE.
isActivated: True hasSession: True
email: shane@xxxxxxxxx accountType: Google
syncEnabled: True version: prod 6083
placeholderThreshold: neverDownload autoUnsyncThreshold: never
downloadThrottlingThreshold: normal uploadThrottlingThreshold: unlimited
autoTrashThreshold: never Mounts: 1
xlThreshold: never Backups: 0
Sync Requests: 0
Background Requests: 9
Uploads: 8
Downloads: 0
Trash: 0
Waiting: 8095
Not Allowed: 0
I appreciate your help. I will continue to monitor and if it is just that the task tray doesn’t work whilst big quantity of uploads are waiting for now I am happy with that, as long as the it continues to upload in the back ground.
Regards
Shane
Hi @shane,
I have a feeling that the waiting queue is what is causing the issue with the menu not showing.
You can get additional detail about the uploads adding --uploads to the CLI status command. You can also do with with the waiting queue (–waiting).
It looks like things are moving so, as you said, just let it do its thing and keep an eye on it.
Hi Tony,
Thanks for the CLI commands. Will keep an eye on it.
Regards
Shane
1 Like
Hi Tony,
Just did the --Waiting link, getting a lot of Exceeded Google Drive request limits issues. I know currently google drive for business has a limit of 5 connections. Is there a way to limit the number of syncs threads to 4 or 5 ?
Regards
Shane
Hi @shane,
Right now you can’t control concurrency, but that is something that should be available in our next major release. odrive implements a back-off strategy if rate limits are hit, which is why you are seeing the waiting list growing. If you are uploading lots of smaller files, fast a furious, then you are likely to hit a limit, as Google has some of the most strict rate limits.
Can you send over a diagnostic from the odrive tray menu? I just want to take a look at the specific exception Google is giving.
Hi,
Can this be done with the CLI or should i restart the odriveapp.exe to get access to the Send Diagnostics in the tray icon. The icon is currently non-responsive with the waiting growing. I am uploading a lot of small files.
If i need to reset, I will try to set the uploadThrottling to limited to see if this temporarily restricts the request limit breaches.
Shane
Hi @shane,
Sorry. Yes it would need to be restarted to do this, since diagnostics can not be triggered from the CLI.
If you restart odrive, see if you can have it run for a little bit before sending.
Thanks!
Hi Tony,
Sent. Hope this help diagnose some issues. I have switched to limited upload and now about 4K waiting.
Regards
Shane
Hi Tony,
It is still becoming full non-responsive after a few hours. After about 6 hours it looks like it stopped being responsive and nothing gets synced and CLI status update doesn’t return anything until i kill the process. Is there a way to disable the tray menu system through CLI?
Regards
Shane
Sorry for not having read any of the responses, but setting odrive to empty trash immediately and letting it sit for several hours helped me a lot.
Hi @shane,
It looks like it is running into a memory constraint due to the number of objects piling up. I actually wasn’t able to get a clean diagnostic (it was an exception dump instead). Is it possible to break up the files into smaller chunks to make them easier to digest?
Can you tell me how many files/folders we are talking about?
I’d just like to add to this topic another issue that I think might be relative to this problem. It has to do with OSX and NTFS volumes.
I have an external NTFS drive connected to OSX Sierra of which my odrive folder exists at root level. OSX’s built in NTFS drivers are terrible and eventually cause corruption of the drive (so far temporarily), something having to do with journal flags, dirty unmounts or similar? The 3rd party Paragon NTFS driver software resolves this but at this time has proven to be incompatible with odrive causing mass CPU usage so I have elected to continue using the native NTFS drivers.
Anyway, when this occurs, file and folder access is wonky, for example, my root odrive folder now has thousands of files that shouldn’t exist there but should actually reside within sub-folders. Checking dmesg from the command prompt tells me what to do and that the drive is dirty. I then boot into Windows, the OS I loathe and repair the drive by letting it fix the indexes/journal.
This always seems to fix the problem and my files so far have always all recovered to the right locations but I still end up with thousands of files in the deleted items list resulting in this problem (reported in this thread) which seems apparent that it is due to the sheer volume of files in the deleted items list. The very same files that were showing up in the root folder but again appear to be copies from the OSX NTFS driver mishap.
I need my external drive to be readable and writeable across OSX, Windows and Linux as in my line of work I use all 3. I also need to support large folder depth and large files over 4GB as many are images of systems. I’ve tried exFat but end up with issues in Linux taking me back to NTFS as the lesser compromise. I feel like I can’t win here, any suggestions?
Hi @p_ingram3541,
This won’t be a problem in the next generation of odrive, it is something that can be hit, currently.
When you hit this case what do you end up doing? Are you using the CLI command to empty the trash?
At this point I am worried about file loss. I have shut down the sync client and am running to go pick up another drive so I can sync everything down from the cloud on a fresh OS and then run an extensive compare against the two drives to find out what is junk and can be delete and or if I have any lost data I should be concerned about. I love odrive but I am worried for my data, if you don’t mind me asking, what is the best approach to protecting my data in the cloud from syncing up when drives become corrupt?
Hi @p_ingram3541,
I didn’t know that the NTFS support on MacOS was that bad. Sounds awful.
Since you need to access data across different OS’s, can you instead use odrive’s progressive sync and unsync to maintain separate storage on each machine, but only locally caching the items you need at that time? Or, do you need to have all of that data available on all systems?
As for preventing syncing corrupted data, there isn’t a whole lot that can be done unless you are keeping your files as placeholders. There is no data to corrupt on a placeholder file. There is a post here regarding ransomeware, which I think has some relevant info that applies here, if you want to give it a look.
Thx @Tony I got everything situated now. I have chosen to keep an offline copy that I will sync from a Windows environment at periodic intervals so that I can continue to use my portable NTFS drive across all 3 OS’s. I only need to sync down at will so the placeholder approach is a great suggestion and eliminates having to have different drives for different OS’s.
1 Like