sausages

Unintentional Guinea Pig Diaries.
Day 8 - Entry 1
I spent the rest of yesterday licking my wounds and contemplating a future without my data. I could probably write a horror movie script on those thoughts but it would be too dark for the people in this world. I must learn from my transgressions. In an act of self punishment and an effort to see the world from a different angle I slept in the dogs bed last night. He never sleeps there anyways but he would never have done the things I did. For that I have decided he holds more wisdom than his human. This must have pleased the Data God's because this morning I awoke with back pain and two of my drives mounted and functioning. The original drive which had completed the upgrade, had been working, and then went into "drive initializing"...is now working again. The drive that I had tried to mount and said it was upgrading with no % given has mounted (FYI 15TB Drive with 500GB on it). However my largest drive is still sitting at "Drive queued to perform recovery".
Maybe one more night in the dogs bed will complete the offering required to the Data God's
End Diary entry.
 
(P.S. Just in case you wondered...that spoiled dog has "The Big One" Lovesac as a dog bed.. In a pretty ironic fashion their website is down. #Offering) 

At least you have a percentage showing on yours...

OK. My mistake, then. I haven't started this process, I just thought I remembered this fact from some rClone work I've done previously. I'll remove that comment.

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

Unintentional Guinea Pig Diaries.
Day 7 - Entry 1
OUR SUPREME LEADER HAS SPOKEN! I received a response to my support ticket though it did not provide the wisdom I seek. You may call it an "Aladeen" response. My second drive is still stuck in "Drive Queued to perform recovery". I'm told this is a local process and does not involve the cloud yet I don't know how to push it to do anything. The "Error saving data. Cloud drive not found" at this time appears to be a UI glitch and it not correct as any changes that I make do take regardless of the error window. 
This morning I discovered that playing with fire hurts. Our supreme leader has provided a new Beta (1.2.0.1306). Since I have the issues listed above I decided to go ahead and upgrade. The Supreme leaders change log says that it lowers the concurrent I/O requests in an effort to stop google from closing the connections. Upon restart of my computer the drive that was previously actually working now is stuck in "Drive Initializing - Stablebit CloudDrive is getting ready to mount your drive". My second drive is at the same "Queued" status as before. Also to note is that I had a third drive created from a different machine that I tried to mount yesterday and it refused to mount. Now it says "drive is upgrading" but there is no progress percentage shown. Seems that is progress but the drive that was working is now not working. 
Seeking burn treatment. I hope help comes soon. While my data is replaceable it will take a LONG TIME to do. Until then my Plex server is unusable and I have many angry entitled friends and family. 
End Diary entry.

If there is an option built in, submit it to Kaspersky for review. 
 
This is DEFINITELY a false positive.  
 
Additionally, the "HEUR" prefix indicates that this is a Heuristics match.  Heuristics is a predictive algorithm for virus detection, and much more prone to false positives based on bad predictions. 
 
 
 
Additionally, if you check the file yourself, it is digitially signed, and the chain of custody up until the signing can be 100% guaranteed by Alex (the developer). Meaning there is no opportunity for malware to have made it into the software. 

Was going to post about this, but you beat me to it. 
 
And yeah, 1.0.0.745 should fix the issue. 

Unfortuantely, that is hard to tell.
 
StableBit Clouddrive doesn't deal with files directly.  It deals with chunks of disk data. Period.  
 
Running a CHKDSK pass will actually check the file contents and look for "problems" (eg, where part of the data is allocated properly, and part isn't). 
 
 
 
Bu for the example, the data that would be at risk would be new data or modified data.  The data that is already on the cloud provider and hasn't been changed should be safe from corruption. 
 
 
Again, it's the "new" data that is the problem.
 
 
 
 
However, this issue is something that was considered (literally) from the ground up.  There are bunch of checks to help prevent corruption.  The unloaded data includes checksums to ensure the integrity.  
 
And that's why if the software finds the cache drive (even on a new system), it will attempt to use this to recover the data, rather than losing everything.  You'll need to re-authorize the drive and account, but as long as this cache is intact.... you should be able to avoid any potential corruption.

I agree with "Sausages". I have been testing the system and it works well. I know without encryption keys, I am toast anyway. I just want to ensure that I completely understand how the system works to make sure my data stays uncorrupted. How much of a cache it too much to loose. Obviously best case scenario, I complete uploads to the drive, but I am interested in worse case scenario as this is a data backup solution.  
 
Thanks for the previous reply!