The "Error renaming volume..." error is inconsequential in this case I think. That code is simply trying to retrieve the volume information and see if the volume name has changed. If it has, it would go ahead and update the drive's metadata. Something is going wrong there, but that's not important for this because the volume name is there for UI purposes only.
As far as missing chunks, this is how these errors are handled:
- Missing / corrupt / (and now stale) chunks are all treated the same way as far as drive I/O errors are concerned. Let's call all of these "chunk validation errors".
- Any chunk validation error that prevents the service from retrieving data from the storage provider will trigger a number of retries. If a valid chunk doesn't come back eventually, an error is returned to the disk driver, which in turn returns an error to the application (or kernel subsystem) that originally requested the read from the cloud drive (error code STATUS_IO_DEVICE_ERROR). Basically, to the caller, it looks exactly like a hard drive that's experiencing errors reading the requested data.
- If the application chooses to retry the read, after 3 consecutive read errors (controlled by CloudFsDisk_MaximumConsecutiveIoFailures), the cloud drive is force unmounted.
Missing chunks will generate specific UI feedback errors such as: Chunk N was not found
The log file will record a Warning similar to this:
Warning 0 [ChunkIdHelper:6] Chunk 0 not found (ChunkId='...')
At this point, you can enable:
- Options -> Troubleshooting -> Chunks -> Allow missing chunks
- Options -> Troubleshooting -> Chunks -> Ignore chunk verification
This will allow the missing chunk to be read in as all NULLs and return that invalid data to the caller. This allows you to continue using the cloud drive, even though the provider has lost some of that data. The missing data will obviously be invalid on the drive from now on.
------------------
More advanced information for data recovery purposes:
- Missing chunks are detected by using an SQLite database located at %ProgramData%\StableBit CloudDrive\Service\Db\ChunkIds
- The database file name is the UID of the cloud drive. The UID can be shown by going to Options -> Technical details... -> Details... (it's under Overview -> UID).
- The exact chunk size in bytes is also in drive details under Chunks -> ChunkSize. This is the size of each chunk from the drive's point of view, and you will need it to convert an LBA to a chunk number. The actual size of the chunks at the storage provider might be larger due to additional metadata (such as cryptographic signatures).
To get a view of all of the chunks that StableBit CloudDrive thinks should be at the storage provider, you can get a free SQLite DB access tool, such as
https://sqlitebrowser.org . Open the appropriate database file and look at the ChunkIds table. This table lists all of the chunks that the cloud drive knows to exist at the provider. Do not change anything in the DB, but if you just want to get a list of existing chunks and their associated provider assigned keys, this is the way to do it.
In order to translate an LBA to a chunk number, you do: LBA * (bytes per sector) / (chunk size in bytes). Integer division is used here.
For example, for an LBA 274,877,906,943 and a 10 MB chunk size on a cloud drive with 4096 bytes per sector:
274877906943 * 4096 / 10485760 = Chunk # 107374182
(offset into the chunk doesn't translate directly into the offset at the provider because of chunk metadata, which is more complicated and beyond the scope of this)
------------------
Finally, the databases of chunk IDs can be deleted and rebuilt by resetting settings from Options -> Troubleshooting -> Reset all settings... (check Reset databases when prompted). This will re-enumerate all of the files that currently exist at the storage provider and repopulate the chunk IDs database.
You should not do this under normal circumstances because, if the storage provider has lost or corrupted some of your data, resetting the database will force StableBit CloudDrive to ignore that loss or corruption and to propagate that invalid data onto your cloud drive as a result. This option is there as a last resort for troubleshooting purposes only.