Christopher (Drashna)

As I've been using linux more and more, the main/only thing keeping me on Windows is our software (and well, gaming, but even then ... valve has made that so much easier)... so I feel you. However, it's a complex issue. And that's not even counting distribution of the software... But at this time, no. Sorry.

For the mount points, at any time that the drives are connected to the new system. Personally, I would recommend changing the volume labels for the drives to match their locations/IDs, so that it's easier to identify the drives. Also, if you're using StableBit Cloud, it should sync the settings for the pool in StableBit DrivePool, and should sync the scan history and settings for StableBit Scanner, on the new system.

If this was the case, then it may be that the "SYSTEM" account permissions were changed or corrupted. This accound should have full control on the pool. This is the account that the service runs in, and uses for accessing the pool for balancing, duplication and drive removal. The "forced damage drive removal" option should skip problem files and continue with the removal, though.

For reference, you can manually merge pools, if needed. https://wiki.covecube.com/StableBit_DrivePool_F1655

It might be worth running this on both systems: https://wiki.covecube.com/StableBit_DrivePool_Q7420208

the pool does support adding multiple drive letters to a single disk (well, really, it's windows thing, and is supported). As for the delete/undo, the pool does support the recycle bin, but that depends on the specific settings you have configured.

Also, the system Event Viewer can give you an indication for why it failed. In fact, with support tickets, it's one of my first go-tos for troubleshooting weird issues. If you're seeing a lot of disk errors or the like in the event viewer, it can indicate an issue. Also, the burst test in StableBit Scanner can help identify communication issues with the drive.

welcome!

That is the pool drive. The 2048GB size exactly, that is the giveaway, and the "COVECUBECoveFsDisk_____" is just confirmation of that. (that's the driver name). I'm not sure why that happened, but uninstalling and reinstalling StableBit DrivePool can also fix this. And the drive is always reported as that size, in that section of Disk Management. But elsewhere it shows the correct size.

That's a hard question to answer. SSDs tend to be fast, including in how they fail. But given this, I suspect that you might have some time. However, back up the drive, for sure! Even if you can't restore/clone the drive, you'd be able to recover settings and such from it. But ideally, you could restore from it. And cloning the drive should be fine. Most everything is SSD aware anymore, so shouldn't be an issue. But also, sometimes a clean install is nice.

Would you mind opening a ticket about this? https://stablebit.com/contact/ This is definitely diving into the more technical aspects of the software, and I'm not as comfortable with how well I understand it, and would prefer to point Alex, the developer, to this discussion directly. However, I think that some of the "twice" is part of the upload verification process, which can be changed/disabled. Also, the file system has duplicate blocks enabled for the storage, for extra redundancy in case of provider issues (*cough* google drive *cough*). But it also sounds like this may not be related to that.

Make sure that you're on the latest release version. There are some changes to better handle when the provider is read only (should be at least version 1.2.5.1670). As for the empty chunks, there isn't really a way to discern that, unfortunately. If you have the space, the best bet is to download the entire directory from Google Drive, and convert the data/drive, and then move the data out.

In general, this shouldn't happen, but certain scenarios seem to trigger this more. Namely the large semi-annual updates for Windows 10/11. But if you do seee this happening, open a ticket, and then run the StableBit Troubleshooter, and let us know when it's complete.

Given the read errors and the NVMe Health warning, I would definitely recommend replacing the drive.

Mostly, it's just accessing the disks via the poolparts. Otherwise, it is theoretically possible. You could use dism tools to install the drivers for the pool into the winPE image, but you'd also need to mount the image, and manually add the drivepool service. This is complicated, and I'm not entirely sure that this will work.

Awesome, thanks. And my guess is that it's probably using an API in a way that is either wrong, or handled wrong by the pool. Though, it could be something else, too.

Unfortunately, no. It would take some code changes to facilitate that.

Glad to hear it! If it happens again, let us know and open a ticket!

Adding a drive to the pool isn't really backing it up. There are programs that can do that, but this isn't the way. If you just want redundancy, then that's absolutely possible. The simplest way, add the existing pool to a new pool, and add the large disk to that "top level" pool. Enable duplication on that pool, and "seed" the pool from the other pool. Eg, do this: https://wiki.covecube.com/StableBit_DrivePool_Q4142489

That's very odd. I'm guessing it's something to do with the API that they're using, as I have a number of games installed to the pool, and don't experience any sort of issue like this. That said, if you could get logging of this, it would go a long way. https://wiki.covecube.com/StableBit_DrivePool_2.x_Log_Collection Eg, enable logging, reproduce the issue, then exit and stop the logging as soon as it occurs. And note the exact time, if possible. Then open a ticket at https://stablebit.com/Contact and report/repost it there.

Could you open a ticket at https://stablebit.com/Contact After doing so, run the StableBit Troubleshooter: https://wiki.covecube.com/StableBit_Troubleshooter And then try resetting the settings: https://wiki.covecube.com/StableBit_DrivePool_Q2299585B

Worst case: https://wiki.covecube.com/StableBit_DrivePool_Q3017479 And then reinstall the software.

The safest option would be to detach the drive, change API keys, and re-attach. However, you *should* be able to just re-authorize the drive after changing the API keys.

Try rebooting. If that doesn't help, try resetting the settings in StableBit DrivePool. https://wiki.covecube.com/StableBit_DrivePool_Q2299585B If that doesn't help with the missing disk, remove the disk in the UI, and then do this: https://wiki.covecube.com/StableBit_DrivePool_F1655 And the recycle bin should be the one on the desktop. It's a combined list of all of the drive's recycle bin.

FAQ answers that, as did I, above. You can generate your own app API keys and use those, these are configured in "C:\ProgramData\StableBit CloudDrive\ProviderSettings.json" file. The Google Drive Provider will be marked as "expirmental"/"deprecated". This means that new installations, the provider will be hidden by default. You can enable it by enabling experimental providers. However, if you already have connected to Google Drive on a system, then it will stay visible. Fully outlined here: https://wiki.covecube.com/StableBit_CloudDrive_Q7941147