1.8.0 Graceful response to invalid drive reference

I use a virtual drive (via ImDisk) and, until recently, assigned it to Drive H:. The addition of a card reader compelled me to reassign it to Drive J:. Upon loading my Scrivener project, I got repeated, inescapable system level prompts to insert a disk in drive H:.

So I made a drive H: again, just to load my project and see if I could track down what in it was calling for my ram drive. Turns out, I believe, that I had experimented with Scrivener Preferences settings months ago, and still had H: as the goto drive for saved prefs. Not a path Scrivener actually needed to load the project or the active prefs, just the first path it’d try to display if I started tinkering with prefs again.

In any event, I’d request Scrivener test for the existence of a necessary drive or folder, and throw up its own error if it’s not available, to give the user an escape route and an indication of what to fix.

Rgds – Jerome

Update: Scrivener continued to seek Drive H even after I’d changed the Preferences load and save path. But I’ve cleared the Recent Projects menu, and that seems to have quieted the seeking. Quite possible I had a test project on H at one time, and that its name lived on in Recent Projects.

If an invalid drive among unloaded Recent Projects thwarts the live-path project we’re actually trying to load, I think we can fairly call that a bug.

Rgds – Jerome

Hello Again

Another invalid drive reference lockup occurs when the invalid drive is the root of a Document References entry. The user is locked out when merely attempting to edit the document, not even clicking on the reference. But even if the user clicks, the error should be recoverable.

In a cloud environment, document references will naturally refer to drives that may come and go. The user should not be expected to maintain perpetual connections to all the drives represented in a project’s doc refs. Especially without a graceful escape route.

Thanks for considering, however quietly.