My Synology NAS drive has stopped working. Now Scrivener keeps slowing down for up to a minute and displaying a message that the drive is not available; this happens twice for each cursor movement or character.
I have turned off Notifications – Show Notifications Preview; but the same delay occurs when pressing Page Down. Is there a way to stop this annoyance?
I assume your Scrivener project (or related data like linked images) isn’t located on the defective drive right now, but it sounds like your backup location still points there. (Please check under Scrivener → Settings… → Backup / Scrivener → Project → Project Settings… → Backup.)
Where did you get that one from? The latest version is 3.3.1 (15588) as of now.
Weird. And this only happens in Scrivener? I could imagine some other tool getting tripped up by the missing drive and thus somehow slowing down all file access (in theory), but you’d notice that everywhere.
As a test, could you uncheck Scrivener → Settings… → General → Saving → Autosave after X seconds…
Shouldn’t make a difference, since it should autosave to the new (not NAS) location, but who knows.
Open Scrivener without any projects (or close any open projects), then open the desired project from Finder (which will presumably not point to the NAS). This sounds like there’s an old reference hanging around somewhere.
Also, if there are any aliases or linked images in the project, make sure they aren’t on the NAS either.
What I meant to say was that the drives inside the machine had reached the end of their useful lives. I copied the data to a new Synology drive (with which I am also having a problem). I suppose I could replace a new drive in the old NAS drive.
If the drives truly are failed and no longer responding to the system’s requests in a timely manner, then you might just be looking at how most operating systems struggle with this particular situation. It can happen for other reasons as well, such as a network failure or a shared folder on a machine that has gone into sleep mode—basically any file system request that might need to poll the drives for status can lock up anything that initiated that request, until it eventually times out and responsiveness is restored. This can be a file dialogue box, or as someone mentioned above, it could be a background look-up like the Scratch Pad folder, opening new Finder windows, viewing anything with a symbolic link or perhaps even an alias pointing to the location that is offline (for example an alias in the binder, where any action that might cause it to look for the original file might cause a lock up—which could be as simple as viewing a corkboard that includes it), etc.
In short, it’s a good idea to figure out why Scrivener is periodically looking there, because it’s probably something important that you want to relocate, but you can probably avoid all of these lock-ups by unmounting the device, or failing that, powering it down. Then at least you’ll get a much more immediate “resource cannot be found” type error because now it is looking for something that doesn’t exist, rather than something that leads to a device that never says “hey, I’m okay, here’s the thing you want” back to the system.