Jump to content
  • 0

Drive will not mount


Freppa

Question

I updated to version .834 this morning. Now I cannot get the drive (Amazon Cloud) to mount at all. After a while I get "HTTP 429 error". Any thoughts?


edit: For clarification: It was working flawless prior to upgrade.


​The service logs shows a lot of activity, including throttling. A snip:

4:24:03.4: Information: 0 : [ChunkIdSQLiteStorage:23]   chunks IDs: 47539,47544,47546,47549,47564,47570,47571,47587,47588,47595,47598,47602,47612,47630,48534,48545,48553,48561,48569,48574,48575,48597,48603,48605,48622,48623,48631,48634,48636,48640,48647,48649,48653,48674,48678,48680,48685,48691,48694,48695,48698,48705,48711,48716,48726,48728,48731,48732,48750,48759,48780,48782,48783,48784,48805,48808,48817,48831,48840,48848,48854,48855,48887,48892,48906,48913,48926,48931,48947,48956,48987,49007,49008,49010,49020,49023,49027,49030,49040,49065,49068,49083,49089,49094,49098,49112,49115,49118,49123,49127,49128,49144,49147,49155,49160,49179,49181,49202,49215,49219
4:24:03.6: Information: 0 : [ChunkIdSQLiteStorage:23]   chunks IDs: 47620,47627,47631,47643,47645,47646,47665,47682,47708,47710,47711,47742,47757,47762,47780,47787,47788,47798,47805,47821,47829,47851,47872,47877,47892,47896,47901,47905,47927,47930,47937,47943,47956,47959,47987,48020,48023,48045,48063,48071,48083,48086,48096,48106,48107,48126,48129,48167,48176,48185,48189,48190,48198,48201,48203,48216,48219,48220,48229,48240,48259,48260,48263,48274,48288,48301,48308,48313,48316,48326,48331,48337,48341,48351,48370,48372,48377,48415,48416,48419,48423,48429,48436,48466,48472,48474,48483,48486,48487,48501,48502,48518,48528,48539,48541,48550,48562,48563,48576,48579
4:24:03.7: Information: 0 : [ChunkIdSQLiteStorage:23]   chunks IDs: 48586,48589,48598,48602,48608,48633,48644,48648,48679,48684,48687,48693,48696,48700,48703,48714,48721,48723,48725,48727,48729,48738,48740,48751,48764,48773,48776,48778,48794,48795,48797,48807,48811,48823,48829,48914,48941,48944,48945,48955,48969,49006,49009,49013,49014,49019,49048,49049,49051,49059,49079,49080,49084,49086,49091,49095,49101,49102,49105,49109,49133,49150,49165,49177,49178,49187,49198,49205,49206,49210,49212,49213,49221,49244,49246,49257,49263,49272,49278,49280,49283,49313,49314,49315,49327,49333,49334,49337,49339,49349,49350,49355,49358,49363,49368,49384,49398,49408,49409,49422
4:24:04.1: Warning: 0 : [ApiAmazonCloudDrive] Server is throttling us, waiting 1,000ms and retrying.

post-3277-0-96259800-1486825989_thumb.gif

Link to comment
Share on other sites

14 answers to this question

Recommended Posts

  • 0

I'm glad to hear it! 

 

As for "authoritative mode", this has to do with the Chunk ID system.  

 

 

* Added a persistent file ID storage database for providers that don't have the ability to download files by name (Box, Google Drive):

    - This is designed to reduce the number of API calls that need to be made to these providers when downloading chunks.
    - Each cloud drive now has its own local persistent file ID database.
    - The new persistent database can operate in 2 modes, authoritative and non-authoritative.
        - In authoritative mode, the provider is never queried for file IDs because the database knows about all existing IDs.
        - In non-authoritative mode, chunk IDs will never be re-queried again once they are looked up once. This is less efficient than 
          authoritative mode but allows for backwards compatibility with existing drives.
    - All newly created drives will operate in authoritative mode.
    - All existing drives will operate in non-authoritative mode.
    - If the file ID database is damaged or missing, the drive will be converted to use non-authoritative mode. Losing the file ID database 
      will have no impact on the data integrity of the cloud drive.
    - When upload verification is enabled, chunk IDs will no longer be re-queried from the provider when verifying a chunk. This behavior can 
      be changed by setting ChunkId_RequeryOnVerify to True.
    - Persistent file ID storage can be completely turned off by setting ChunkId_Persistent to False. This will revert back to the legacy 
      in-memory file ID cache. Re-enabling the persistent store after disabling it will put all cloud drives into non-authoritative mode.

 

Basically, the difference here is that non-authoritative mode doesn't fully index the drive, and as the drive is used, it may/will index the drive.

 

Authoritative mode requires that the entire drive be indexed. 

 

The advantage for the authoritative mode is that it significantly reduces the number of API calls made, and it allows us to definitely track the files. 

Link to comment
Share on other sites

  • 0

Oh I encounter this too. Is this a new feature?

 

"yes".  It's not a new feature per say, but one that we are enforcing from here on out.  THis won't affect new drives unless you manually delete the database, But this will happen the first time you mount an existing drive that hasn't been indexed fully. 

Link to comment
Share on other sites

  • 0

"yes".  It's not a new feature per say, but one that we are enforcing from here on out.  THis won't affect new drives unless you manually delete the database, But this will happen the first time you mount an existing drive that hasn't been indexed fully. 

Mine stopped and this message is in the logs

Warning: 0 : [OAuth2TokenBase:59344352] HttpProtocolException refreshing token. HTTP Status BadGateway

 

Edit: Rebooted and fix the problem.

Still getting chunk id's though

Link to comment
Share on other sites

  • 0

"Bad gateway" generally indicates a network connectivity issue.  

 

If it's having issues communicating with the internet ... well, that would DEFINITELY cause issues with mounting the drive! 

 

That said, I'm glad to hear that a reboot did fix the issue. 

And yeah, it will take a while to complete the indexing. Once it's finished, you shouldn't need to do so again. 

Link to comment
Share on other sites

  • 0

"Bad gateway" generally indicates a network connectivity issue.  

 

If it's having issues communicating with the internet ... well, that would DEFINITELY cause issues with mounting the drive! 

 

That said, I'm glad to hear that a reboot did fix the issue. 

And yeah, it will take a while to complete the indexing. Once it's finished, you shouldn't need to do so again. 

After a few hours mine was stuck @ 601 then I rebooted then it started all over again

Link to comment
Share on other sites

  • 0

COuld you upgrade to the latest version? 1.0.0.843

http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.0.0.843_x64_BETA.exe

 

If the issue continues, then could you enable tracing, reproduce the issue?

http://wiki.covecube.com/StableBit_CloudDrive_Drive_Tracing

And then upload the logs:

http://dl.covecube.com/Troubleshooter/StableBit.Troubleshooter.exe

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...