Jump to content

Christopher (Drashna)

Administrators
  • Posts

    11700
  • Joined

  • Last visited

  • Days Won

    388

Posts posted by Christopher (Drashna)

  1. 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.  

  2. On 4/19/2024 at 5:02 PM, billyboy12 said:

    *EDIT* Seem it was a permission issue in the end! I followed the guide at https://wiki.covecube.com/StableBit_DrivePool_Q5510455 and this fixed it, I was able to remove the drive!

    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.  

  3. 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. 

  4. 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. 

  5. 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. 

  6. 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.  

  7. 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.  

  8. 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

  9. 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. 

  10. 5 hours ago, thestillwind said:

    Will you let the option available to people that want to use it with the risk associated or you will remove it from the list of choice ?

    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. 

    19 hours ago, The Tran said:

    Where can I find instructions to get my own API Key to use?

    Fully outlined here: 
    https://wiki.covecube.com/StableBit_CloudDrive_Q7941147

×
×
  • Create New...