TLDR: It still looks to me like Google is not listing those chunks to us when enumerating files in a folder, and as a result, StableBit CloudDrive is assuming that the chunks don't exist.
In order to address this, I've done a number of things here. First, I've updated our API code to use v3, which includes some changes to how files are listed. Perhaps this newer API will not have these listing issues. Second, the service will now log which chunks are returned by Google's directory listing API, by default. This will clearly show which chunk numbers Google is returning to us, and you should be able to clearly see where the problem is.
Also, it's worthy to note that this issue should not affect new drives, because they don't need to enumerate chunks.
Here's a little mini-FAQ on chunk IDs and Google:
When are files enumerated from Google Drive?
Any existing cloud drives that are running in non-authoritative chunk ID mode will perform a full directory listing at mount time and populate the chunk ID database.
What's non-authoritative chunk ID mode?
That's when the chunk ID database is missing either from the local system (for attached drives), or from the provider (for detached drives). This normally only happens when you reset databases (using Reset all settings from the Troubleshooting menu).
Legacy drives that were created with versions prior to 1.0.0.810 can also be in non-authoritative mode.
What about new drives?
New drives never enumerate chunks. Since a new drive has no chunks stored at the provider to begin with, and it keeps track of all of the uploaded chunks, it has perfect knowledge (authoritative mode) of which chunks should exist at the provider.
What about detaching and attaching drives?
Detaching and attaching drives preserves our chunk ID database, and so there is no need to enumerate chunks from the provider.
Do we ever query Google for individual chunk IDs after mounting for any reason?
No, not for Google Drive, not anymore. If a chunk that we know is supposed to be there is actually missing (e.g. 404 HTTP error), normally, an I/O error is reported. If "Allow missing chunks" is checked under the Troubleshooting menu, the I/O is allowed to succeed with empty data (nulls).
How would you force StableBit CloudDrive to re-enumerate chunk IDs using the new v3 API?
- Reset all settings from the Troubleshooting menu, including the databases.
- Reauthorize the drives.
- Wait for the drives to finish mounting.
All of the found chunk IDs will be logged in the service log for troubleshooting purposes.
What does a chunk enumeration look like in the logs?
Something like this:
[ChunkIdSQLiteStorage:20] Set chunks IDs...
[ChunkIdSQLiteStorage:20] chunks IDs: 306,315,319,320...
This information is current as of version 1.0.0.822.