Christopher (Drashna)

Dang. If you could open a ticket at https://stablebit.com/Contact

okay, glad to hear that

I'm glad to hear that!

Glad to hear it!

Honestly, we're not entirely sure what the issue is. Since it's impossible to reproduce for us, it's a lot of guesswork. However, the fact that people have not seen checksum errors when this happens indicates that the data itself isn't corrupted. So, the most likely reason is that old data is being returned. This would pass the checksums with flying colors, but the data would be out of date. If that was file system data, that would lead to a corrupt file system. Which ... sounds like what is exactly what is going on. So the changed code actually stores the checksum locally (and uploads it to the cloud provider when detaching the drive), so that it can compare what is pulled from the cloud and what we know should be the latest version of that chunk. This will prevent stale data from being downloaded, and unmount the drive, if it happens too much.

Unfortunately, no, there isn't. It's been asked before, but we don't have any plans on adding an option, since it introduces too many potential issues.

Worst case, deactivate the licenses first, clone, and then reactivate. I know we check the system drive for the licensing, but I think that cloning the drive doesn't change the info we look at.

It won't affect it if you manually trigger a balancing pass, but it should prevent the SSD Optimizer balancing plugin from triggering passes when you don't want them.

There isn't a licensing portal. All licensing issues are handled at https://stablebit.com/Contact

Try resetting the settings: http://wiki.covecube.com/StableBit_DrivePool_Q2299585B

If you haven't already, head to https://stablebit.com/Contact

Sorry, no, there is no scheduler built int, right now.

Could you open a ticket at https://stablebit.com/Contact

@nagetech Try the latest beta. We did find some issues with read striping: http://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.2.3.978_x64_BETA.exe Also, we added a testing tool for Read Striping: http://wiki.covecube.com/Downloads#Other_Tools It's the File Read Simulator program.

Sorry for the absence. To clarify some things here. During the Google Drive outages, it looks like their failover is returning stale/out of date data. Since it has a valid checksum, it's not corrupted, itself. But it's no longer valid, and corrupts the file system. This ... is unusual, for a number of reasons, and we've only see this issue with Google Drive. Other providers have handled failover/outages in a way that hasn't caused this issue. So, this issue is provider side, unexpected behavior. That said, we have a new beta version out that should better handle this situation, and prevent the corruption from happening in the future. http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.1.1.1114_x64_BETA.exe This does not fix existing disks, but should prevent this from happening in the future. Unfortunately, we're not 100% certain that this is the exact cause. and it won't be possible to test until another outage occurs.

There is the "running file" setting for DrivePool: http://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings#DrivePool You could check for that file.

Actually, I feel ashamed for not thinking of this myself. That would actually be the best way to back up the system, and not back up all of the data twice.

Sorry for the absence. To clarify some things here. During the Google Drive outages, it looks like their failover is returning stale/out of date data. Since it has a valid checksum, it's not corrupted, itself. But it's no longer valid, and corrupts the file system. This ... is unusual, for a number of reasons, and we've only see this issue with Google Drive. Other providers have handled failover/outages in a way that hasn't caused this issue. So, this issue is provider side, unexpected behavior. That said, we have a new beta version out that should better handle this situation, and prevent the corruption from happening in the future. http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.1.1.1114_x64_BETA.exe This does not fix existing disks, but should prevent this from happening in the future. Unfortunately, we're not 100% certain that this is the exact cause. and it won't be possible to test until another outage occurs.

Sorry for the absence. To clarify some things here. During the Google Drive outages, it looks like their failover is returning stale/out of date data. Since it has a valid checksum, it's not corrupted, itself. But it's no longer valid, and corrupts the file system. This ... is unusual, for a number of reasons, and we've only see this issue with Google Drive. Other providers have handled failover/outages in a way that hasn't caused this issue. So, this issue is provider side, unexpected behavior. That said, we have a new beta version out that should better handle this situation, and prevent the corruption from happening in the future. http://dl.covecube.com/CloudDriveWindows/beta/download/StableBit.CloudDrive_1.1.1.1114_x64_BETA.exe This does not fix existing disks, but should prevent this from happening in the future. Unfortunately, we're not 100% certain that this is the exact cause. and it won't be possible to test until another outage occurs.

That's very odd. Is this still happening?

No reason to get nasty here. That said for shared accounts, generally, we don't support them. For instance, we do NOT support Google Team Drive, for this reason and technical limitations. And sharing the account means that anyone with access to it could mount the drives, potentially corrupting the data. So, renaming it doesn't really have any benefit here, other than as a placebo for your peace of mind. It would be much better to restrict who can access the account.

That depends on what you mean. Most other programs make calls to VSS. It would ONLY be disk drivers that would need to deal with VSS calls to the file system. And then, only file based solutions that would need to, as block based solutions are file system agnostic.

Sorry. For some reason you were flagged as a spammer. I've unflagged you, and you should be able to post properly now.

Unfortunately, it's probably relying on some feature that we don't support. I'm not sure there is much that we can do. But yes, it's absolutely fine to open a ticket and send logs about this.

This issue is fixed in the beta version of StableBit DrivePool, actually.