kird

Sorry, this rule since i have been paying my last gdrive, approximately 3 or 4 months, already existed as it was commented in telegram groups at the time. I don't invent anything, mate.

you mean "The limit for this folder's number of children (files and folders)" that rule is not new at all, contrary to what some here are saying.

I don't know what's going on with the official support, it was pretty seamless before, I don't know what circumstances may be going on right now.

no doubt this is the mission for the braves who jump the cliff without a grid.

In my experience if it is the same hardware and the same operating system there is no need, only if it is a different operating system.

Personally if I am not forced to do it I will be perfectly as I am now, I don't want to think for a second about doing this with 121TB of data... if everything goes well without any loss in the process, I am sure, it would be more than months in doing the whole process. Note to developers, please for people who don't have any problem we hope that future stable releases of SCD don't force us to do the migration because of the API issue, please develop versions where we are not forced to do this step since we don't have any need at the moment and we have been already with gdrive for years, this will not change if there is no need to apply our own api.

Look how many clients have this problem in their gdrive with StablebitCD, everyone here (not too many) reporting the error has something in common, they all had their own api configured, this is what really changed in google that makes this error that is being reported. I haven't seen anyone say they have this bug with the standard api. Without getting into technical details, it's clear that this is not an SCD incompatibility but an API incompatibility, in my case I didn't need my own api to work with my gdrive on a daily basis. Perhaps others have needed it. If you feel more safe upgrading to beta when you say you are not having problems yourself... go ahead and get lucky.

The logic suggests that the version you've been in most of the time has never had this problem... it's totally compatible with google limitation/imposition, in fact this one has always been there, it's not new, another thing is that we (not the developers) didn't know it.

Here one with 121 TB used and without any problem, so i don't need anything and even less to lose my data by doing an upgrade that i don't need at all. Perhaps the secret lies in not having configured any personal API (I've always been with the standard/default google api).

my advice, don't even think about upgrading.

Have any formal announcements been made by the developers? How much hurry to migrate to a new system with a beta version that you don't even know what it leads to... I do not intend to adopt this system, if that is the case, without first making an official announcement by developers, with 130 TB I do not think it is a good idea. That said, with my current version, which is by no means the last stable one officially released, I have no problem with Gdrive at the moment, everything is perfect. To say that I have the standard google api.

So far, with google's own api, I haven't had that kind of error and my files take up more than 100 TB

Do you use the latest stable version of CloudDrive?

If you have the API set up in your CloudDrive configuration, try disabling it. Look at this post which may be related.

I don't have my api configured and I have never met that error, maybe these google guys have touched again something related to the API causing the program to fail. Probably because of what you're saying. Looks like the developers are on vacation.

I'm glad you were able to fix that nasty error on your own. By the way, which version of CloudDrive are you using? I can tell you that in my case there is a version that I keep as a real gem because it is like the "holy grail" for all kinds of errors that the drive may involve. This version is v1.1.0.1051

I have never been able to download or upload anything via gdrive web, all content is encrypted. How do you do it? In my case to upload/download content always through the mounted network drive or Air Explorer (great for managing clouds) but never from the google web interface. Yup, hopefully they can fix this nasty error or give information.

In your image I don't see any appreciation for having exceeded the limit. I wouldn't know what else to tell you. Let's wait and see what the developers say, it's a error which must be verified where it can come from and it's basic to know. I guess now your gdrive is not operational, right?

That information gives you the error we talked about but it doesn't show anything of the total files/folders contained in a root folder. At least I can't see it. When I say look at your locally mounted unit (it's decrypted) I mean this. As you can see in the image it's still far away from the 500,000

From the numbers shown there, it doesn't seem to be your case at all. This can be best traced from the unit mounted on your PC and looking at your Gdrive's statistics. Let's see if the developers can shed some light on the subject.

Yes, i was referring logically to the recycle bin of your gdrive account, the windows one here plays no role. As I understand it here the point is not the amount of Gb/Tb in files on the drive but the total number of folders that can be nested in the account. If I understand correctly, according to this information the error occurs when it reaches 500.000 folders, files... inside a root folder in the drive. "A numChildrenInNonRootLimitExceeded error occurs when the limit for a folder's number of children (folders, files, and shortcuts) has been exceeded. There is a 500,000 item limit for folders, files, and shortcuts directly in a folder. Items nested in subfolders do not count against this 500,000 item limit."

Figuring it out, have you deleted the files from the recycle bin? If you have not configured it in a special way, by default the deleted files go there and if they are not deleted they still count for space.

I know Googledrive has a file and folder limit, but now I don't know what the number is. In my case I'm not having, for now, this error but due to the large amount of folders and files I have on my drive I don't think I'll have much left to overcome it. Good news that our DriveCloud will warn us about that error.

Thanks Christopher, unfortunately it didn't work out, fire out this: from admin cmd --> sdelete64 -s I:UNT\oue Error deleting I:UNT\oue: The file or directory is damaged or unreadable. any other suggestions? Thanks for your time. ps: instead if I create a normal directory with files inside the Gdrive it is able to delete it.

It would be a very interesting option and more so if it could be implemented from within the program itself without having to dismount (detach) the unit.