steffenmand

My guess is that Windows is trying to make thumbnails for video and image files, thus gets stuck in a state where it has to retrieve x data first. I look forward to the option of having extended data pinned, such as file headers etc. Maybe they might come in soon, as we are getting a release out soon

Seems only to run on a global setting - would be nice to have it per account instead! Btw hope all is well after the surgery! Get well!

Just connect the account on the new server and you should be able to force an attach

updates resets it currently

They should just add the option to the UI to change the amount of errors before a dismount. Currently it can only be changed by editing the settings file directly

Hi, I've noticed that the thread count seems to have been defined globally to be shared between all your drives. As i have several google accounts hooked up, with individual drives, shouldn't it be more logical to have the thread count be defined pr. unique google account ? - They should all have their individual API call caps, which was the main reason for the limit. Would be nice to access files from another account, while also download from the first - right now it would just slow down the progress from both.

Hi, Just noticed that when creating a new drive, the "Verify data" checkbox seems not to take effect when making the new drive. So i have to manually activate Upload Verification Windows 10 .827 Might be fixed in a new version Thanks!

Sorry my fix didn't work for you :-(

go to technical overview and look at the service log. you will get a warning about multiple chunks with the same id and the number it has: search for this on the drive and you should find two chunks. Download the newest (for backup) and then delete it afterwards. do this for all the chunks which have duplicates. after you finish go to troubleshooting - > reset settings and include the databases. reboot and start :-) should mount fine now! if not then reupæoad all the chunks you dowbloaded and make a ticket with stablebit

As long as you backup chunks it should be possible to revert back by uploading then again and reindexing :-) I chose to go for the older ones, as i knew ihad not done any changes since the updates where they were made. so i trusted the old data more than the new, as the new potentially could have faulty data - this was also why my drive went RAW as i had multiple chunks on the chunk which contained the MFT data - the new one was corrupt, the old just fine

Deleting all the newest chunks when we had multiple chunks with the same key worked. drive now mounts properly! Before trying this make sure to backup the chunks so you can fix it again! if you already indexed just restart the indexing procedure by resetting the settings and the database under troubleshooting -> reset settings as your index currently will be pointing to the wrong chunk where we had multiple

Fixed it for all drives which had not gone RAW. The one the went RAW seemed to have multiple chunks on the main chunks. So i just tried deleting the new versions (took a backup) and started reindexing all over to see if that would fix the issues and let it mount properly. I guess one of those chunks hold the MFT data and if it uploaded a new empty file, it would ofc. not be able to mount, because the fix loads the newest version == empty file. Will report back if that fixes the issue with the RAW drive

Newest version fixes this :-)

It's a bug with their new fix for missing chunk id's, i'm pretty sure that they will fix this soon

Don't think they have one - I just know from following the forums daily since very early releases :-D

They have a bug currently causing this. Just be patient and it will get fixed!

Did you try the latest build ? .819 http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.0.0.819_x64_BETA.exe

Did you update the version ? Because that screen comes up every time you update CloudDrive

For me I can see everything fine - it's just when I download files that they get filled with empty data instead of the correct chunk data - all because it lost the reference to the chunk on cloud drive

I got no chkdsk errors after testing - the error is simply that the chunks dont have a reference to the right chunk on the provider.

Well as far as i can see, then the system knows what chunks to use. They are simply just not linked to the proper id on the provider. Thats why we were seeing tons of chunks completing successfully with 0%. I think the big problem with data would arise if the problem was that it lost reference to what chunk numbers refers to which file

I suggest you all open a ticket and reference "425755" which is my ticket. We are all having the same issue It is simply the chunk database which is not getting all the id's of the chunks and then instead putting in empty data.

They have an advanced pinning engine in the feature request list - i believe they want to focus on such things after we get out of Beta

I updated the ticket with all the desired info

Haven't created new drives since the double folder issue, but got 4 other drives which still works. Chunks exists on the provider and I am able to download them through the Web interface! First drive I got this issue on was on the 8th and the second was the 19th so days before and after the outage! It just seems like it skips the download and fills in empty data