Jump to content
Covecube Inc.

kird

Members
  • Content Count

    30
  • Joined

  • Last visited

  1. 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.
  2. 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.
  3. 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.
  4. no doubt this is the mission for the braves who jump the cliff without a grid.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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).
  10. 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.
  11. So far, with google's own api, I haven't had that kind of error and my files take up more than 100 TB
  12. Do you use the latest stable version of CloudDrive?
  13. If you have the API set up in your CloudDrive configuration, try disabling it. Look at this post which may be related.
  14. 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.
×
×
  • Create New...