JulesTop

Another question is, does anyone have another provider comparable or better to gdrive? In terms of costs and quotas?

Update for me. My 55TB are also complete. About 5TB/day. Drive is currently operating normally.

I would not delete the cache. I have a 270TB drive with 55TB used and on 1307 I am upgrading at about 10% per 24 hour period. Which is faster than before. I would stay the course if I were you.

Same behaviour for me. I submitted a ticket today to support.

I'm enjoying your diary entries as we are in the same boat... not laughing at you... but laughing/crying with you! I know that this must be done to protect our data long term... it's just a painful process.

I don't believe that this is the case. Clouddrive would organize it all as one single cloudrive and everything would be in the same directory. I do the same exact thing you do, but with 55TB volumes in one clouddrive, and they were all in the same folder.

I don't think that applies because you can't 're-authorize' the drive once the process begins... at least no way that I can tell.

Oh dear... Did you submit a ticket to support? This will make sure @Alex can take a look and roll out a fix if it's on the software end. I don't think he's on the forums too often.

I'm currently at 12.02%, and I started on June 24th at 6:45am... so it's been over 2 days. I have generally larger files... from 15GB to 60GB, but I'm not sure what affect that has.

I was wondering if this would happen as more and more people begin the upgrade process... The issue is, I don't think you can re-authorize the drive once the upgrade process begins... at least I don't see a way to do this. Otherwise, I would switch back to my own key.

I'm going through the process now. It started at 6:45am this morning and is currently at 2.62% complete... I think this will take some time. But I don't think it actually downloads/re-uploads the chunks, it just moves them. I have 55TB in google drive BTW. Also, as far as I can tell, the drive is unusable during the process, and there is no way of pausing the process to access the drive content. However, it will be able to resume from where it left off after a shutdown. Having said all that, I have to say thanks to @Alex and @Christopher (Drashna) for mobilizing

You called it. I just tried uploading a small file to the content folder directly from the Google drive web interface and got an 'upload failure (38)', same as before. It looks like this restriction rollout is definitely happening. It will be fantastic if @Alex has a solution coming soon! But also good that the default keys are keeping us going for now.

I was on the latest stable (I think the last 4 digits we're 1249) when this occured. After a couple of days, I updated to the latest Beta to try and solve it. Also, I realized that at some point I removed my personal gdrive API credentials from the config file, and this is about the time the issue resolved. I just put back my personal API credentials and re-authorized and the issue came back. I yet again switched back to 'null' (the default stablebit API credentials) and the issue went away again... I wonder if there are higher API limits with the Stablebit credentials. Maybe

So the issue has been "fixed". There must be a bug or something, but not sure if it's on Google's side or stablebit. I deleted the file that I figured it was stuck trying to upload. The file I deleted was about 20GB, and there was over 65GB in queue to upload. As soon as I deleted the 20GB file from my computer (which was on the clouddrive), my upload queue seemed to just resume. It didn't drop by 20GB... It just resumed. Anyway, everything seems to be totally back to normal.

I can download from the gdrive without issue. I can also upload to the root of the gdrive without problem (manually). When I tried adding a file to the clouddrive content folder manually (via the gdrive web interface), it fails. It looks like there is an issue with the content folder... Maybe @Alex or @Christopher (Drashna) can help.