Created drive no longer mapped

[ben98923]

Maybe I'm just not understanding the interface, but I created an encrypted drive with StableBit CloudDrive.  It was working.  But it was no longer mounted after rebooting and I can't figure out if that's expected behavior, and I can't figure out how to re-mount it.

 

The only options I see to try and mount would be "Attach" but that shows me a dire warning saying "Cloud drive already attached to [The computer name I'm already on].  Please detach from that computer before trying to attach it to this one."  I didn't attach from any other computer, just this one, and I didn't crash or do anything unusual.  So, am I supposed to "Force Attach" anyway?  There's also the "Connect" option, but I assume that's just for setting up new connections.  And there's "Create" but that also doesn't seem right.

 

TL;DR: Is my drive supposed to mount on login?  And since it isn't should I click Force Attach even though it was never attached anywhere else?

[Christopher (Drashna)]

Connect is for connecting to a provider, create ... well is to create a new drive.

As for the attach, if it didn't remount properly, then yes you want the "force attach" option here, as the information is out of date.

 

However, could you try the latest beta build. There was a bug we found in regards to encrypted drives, and that may be what is going on here.  Try the 1.0.0.454 build.

http://dl.covecube.com/CloudDriveWindows/beta/download/

[ben98923]

The latest beta didn't resolve the issue.  The drive still wasn't attached after logging in or with GUI up.  I did the force attach and it gave me all the dire warnings about this having been attached to another computer and possible data loss.  I don't have any significant files in there to test for corruption or anything.  Not sure why it would have thought I had connected from another computer.

[Christopher (Drashna)]

Did you do a refresh (windows 10), or change the system name, or delete the hidden temp folder for CloudDrive? 

 

If not, then very odd. And if this happens again, let us know. 

 

 

As for the data loss and force attach error, the reason this is given, is that if the other system still has data to upload, this can cause corruption to occur (think like powering off the drive while the write buffer is still emptying to the disk, which is EXACTLY the case, actually).  That's why it gives such a dire warning in this case. 

[ben98923]

Did you do a refresh (windows 10), or change the system name, or delete the hidden temp folder for CloudDrive? 

 

Nope, none of those things happened.

 

And thanks, I'll let you know if it happens again.

[Christopher (Drashna)]

Nope, none of those things happened.

 

And thanks, I'll let you know if it happens again.

Okay. I just wanted to make sure. 

 

I suspect this was related to one of the many recent fixes, though if it happens again... 

[joss]

Hi,

 

I just updated from StableBit.CloudDrive_1.0.0.463_x64_BETA to StableBit.CloudDrive_1.0.0.470_x64_BETA and ran into this problem. All three (Google) drives aren't attached anymore.
Maybe I should mention that CloudDrive crashed before doing this - it froze after I changed the upload threads while saving/closing the settingswindow and didn't come back to life.

 

The forced attach isn't working, it's refused because the directory for the local cache already exists.

 

I still had files uploading, so I'm not quit sure if I just can delete this folder - but is there any other option?

[Christopher (Drashna)]

Hi,

 

I just updated from StableBit.CloudDrive_1.0.0.463_x64_BETA to StableBit.CloudDrive_1.0.0.470_x64_BETA and ran into this problem. All three (Google) drives aren't attached anymore.

Maybe I should mention that CloudDrive crashed before doing this - it froze after I changed the upload threads while saving/closing the settingswindow and didn't come back to life.

 

The forced attach isn't working, it's refused because the directory for the local cache already exists.

 

I still had files uploading, so I'm not quit sure if I just can delete this folder - but is there any other option?

Try rebooting the system again. 

 

And could you grab the logs from the system?

http://wiki.covecube.com/StableBit_CloudDrive_Log_Collection

Just do steps #7-10, though.

 

 

As for forcibly re-attaching the drives, you can delete the cache folders. The only issue is that this will remove the affected changes to the disk. So you lose any of the newer files. 

So, honestly, I'd rather you hold off on that, and see if we can help fix the issue first. 

[joss]

Sorry for not replying, I was on the fly.
The following is just for your information. I don't need help at this moment.

Obviously CloudDrive deleted the folder bei itself while its first try; it was vanished. So I didn't have the choice.
The last drive I didn't touch was mounted automatically after some hours. Maybe I just should have waited.

The drive with a lot ongoing upload was messed up und unreadable first, but Checkdisk managed to repair it and make it accessible somehow. I'm uploading photos, and most of them were listed with the correct size and date on the drive, but were "empty". The only way I figured out to identify this files was a MD5 comparison with our sync/backup-tool. I hope it's going to be okay now.

 

Please let me know if you are interested in the log files for your concern.
 

[thnz]

The drive with a lot ongoing upload was messed up und unreadable first, but Checkdisk managed to repair it and make it accessible somehow. I'm uploading photos, and most of them were listed with the correct size and date on the drive, but were "empty". The only way I figured out to identify this files was a MD5 comparison with our sync/backup-tool. I hope it's going to be okay now.

 

 

That sounds like the exact issue I encountered, but haven't been unable to reliably reproduce. After the computer crashed while CloudDrive was uploading, some files were corrupted (same size, different hash than the originals). They had been written to disk many hours before the crash. I've been unable to reliably reproduce it - last time it took over 30 resets for it to trigger.