Scary blank files

Can anyone advise me on a very weird phenomenon.

I work on Scrivener projects which are saved to the Google Drive folder on the machine in question. I know working in cloud synced folders makes some people nervous, but it has always worked well for me. I thus can access the latest version of my project on both desktop and laptop machine and as long as I am cautious that everything has saved and synced then all is well.

However in the last few weeks my laptop has started to be unable to read certain documents within the binder and shows them as blank when I navigate to them in the app. Metadata for them is all correct, including status flags and last modified date, just that the text is missing. Yet the text isn’t missing - if I locate the relevant .rtf file within the project folder, it is all there intact. If I switch to the desktop machine, which thanks to Google Drive contains an identical copy of the project, the file opens and displays perfectly. I’ve lost nothing.

Because each local install of the Scrivener client creates backups, I’ve attempted to extract a backup created by the laptop, only to discover the same problem. Copy the laptop backup to the desktop PC and open it up, and once again the text is visible and editable.

There used to be just one file which came up blank, yet the problem seems to be spreading. Today there are about 10-15 individual documents that the laptop reads as blank yet have their text inact in the files on the disc.

The only anomaly within the Files > Docs folder in the project is the docs.checksum file which about a month ago suffered from a sync error and so there is an older conflicted verison present (called docs[Conflict].checksum by the Drive sync app -but as that should just be ignored by the Scrivener (which is only looking for its own docs.checksum file anyway) and in any case is present on both Desktop and Laptop versions of the project, I can’t see how this would be the cause.

Actually to reply to my own posting, I’ve just noticed one crucial difference about the invisible files. They all have a number in brackets after their title, so for example my project contains files named:

94.rtf
95.rtf
96.rtf
97 (6).rtf
98.rtf

But crucially the .links twins for each one files never have the number. Is there a config option I’ve somehow activated on the desktop install of Scriver which is causing these numbers to be appended and which isn’t selected on the laptop causing it to be unable to see the files thus named?

That definitely would cause a problem, because Scrivener is looking for 97.rtf to load the content from the Binder, and it cannot find this file since it is renamed to 97 (6).rtf. I’m not sure where that is coming from, but it’s not from Scrivener (otherwise it would be programmed to detect it). I would suspect the sync server is adding this for some reason, version numbering perhaps?

No matter, if you change the name of this file to 97.rtf and load the project you should see the content appear.

I would like to add though that at this time we strongly recommend avoiding Drive as we have received a statistically significant number of reports involving severe data loss and reversions when using it to edit live projects. We recommend using the alternative method, described in this article about halfway down the page, if Google Drive must be used.

I wouldn’t say that this is reflective of synchronisation in general. It just seems that the specific technology that Google is using is not tuned to handle Scrivener’s intensive disk usage. It is constantly reading and writing to the disk, and my speculation is that this is a contingency they have not coded their system for.