I have a peculiar problem. I have two Scrivener projects. Each of them lives inside a separate password-protected Mac sparsebundle. To open one of the projects I open its containing sparsebundle, then open the Scrivener project. Scrivener is also clever enough that if I select the project from the “Recent Projects” list, it will open the sparsebundle for me (and macOS will gather my password along the way). All of this is normal and fine.
From time to time I will take a folder from one of the projects—I’ll call it “Supply.scriv” and drag it, moving it, into the other project—I’ll call it “Demand.scriv”. So “Demand” contains former folders from Supply.
Now here’s the problem. Let’s say that I hope Demand.scriv but have Supply.scriv closed and its sparsebundle locked. From time to time—namely, when I edit an existing file within Demand.scriv—Scrivener will bring up the password query interface in an attempt to open Supply.scriv.
It’s as if in the graph of files that Demand.scriv thinks are relevant to the maintainance of this project, it believes that some of the relevant files are in the original project, Supply.scriv.
These projects are hidden inside password-protected sparsebundles because they contain sensitive content. I don’t want to open both sparsebundles whenever I edit one of the projects.
How do I break the dependency of Demand.scriv upon Supply.scriv? That is, how to I modify Supply.scriv such that editing it will no longer cause the system to attempt to open Demand.scriv?
I don’t quite get exactly what you are doing. It seems you are using Finder (or some other file mgmt tool) to move Scrivener project packages into one another?
Another thought … is not full disk encryption on your Mac sufficient to protect the sensitive data? The bad dude has to get access to your computer to get the files. How likely is that?
This is the key point of confusion (everything else is more likely ramifications of how a Mac works, not really so much Scrivener). What does that mean? You have both projects open at the same time, and are dragging a part of the outline from one binder sidebar, into the other project’s sidebar?
If so, then:
There is no way to move something in that fashion. You can only copy between projects, then trash the old one and then empty the trash.
And by extension, it is not possible to consider that they were “formerly” in the other project, as singular entities. When you copy or drag items between projects, they are created anew, with the same data naturally, but entirely new copies with no possible connection at the disk level between the two.
So yeah, it does, given how nothing in Scrivener works the way you are describing it, sound like you are actually using Finder to move internal pieces of the projects around. All of this OS level confusion with DMG cross-feed aside, that’s a recipe for disaster for the projects themselves.
I can’t explain why the system is trying to load the other DMG when you click on things in the project (to be clear, all of that is handled at the Mac level, Scrivener isn’t the one being clever here, it is 100% ignorant to any of this). That doesn’t make any sense to me, but then neither does how you got to this point, so I guess that is only in keeping with the precedent.
I apologize. I wasn’t clear, and I think I’ve led you to some false assumptions. I am not using Finder to copy or move the files: I copy them within Scrivener itself, as you described. And like you I assumed that the new project wouldn’t have any connection to the old one. Nonetheless, when I interact with the new project Scrivener attempts to open the old one.
I was going through the process of duplicating the steps by which I arrived here and found that the problem arises even more simply than I described. It definitely has something to do with Scrivener’s own internal operation, not just macOS.
With both sparsebundles closed (locked) and of course both Scrivener projects closed, I create a fresh, new Scrivener project using the “Blank” template I give the project a location and name (not in a sparsebundle) and the project view opens. I then open Scrivener’s Preferences pane (Cmd + comma). Immediately the password prompt to open Supply.sparsebundle appears.
This tells me that something within Scrivener is referencing something inside that sparsebundle even when it’s open with nothing but a blank project.
One hypothesis would be that I might have set my backup folder setting to point to a folder inside the sparsebundle. That would make sense, right? Then when Scrivener went to access my backup folder, it might try to open the sparsebundle. But no, my backup setting is aimed at the default setting in ~/Library… I checked all the other settings I could think of, and none of the visible settings point into the sparsebundle. But apparently some internal (perhaps invisible?) setting does.
The Recent Projects lists (one on the welcome screen, one on the application menu—they’re slightly different in behavior) do point to that project and therefore that sparsebundle, of course. But the existence or display of that list shouldn’t and doesn’t try to open the sparsebundle.
I suppose the most practical question I can ask is: where does Scrivener store its internal settings files? If they’re in a format I can read I can search them for a reference to the sparsebundle and find out what’s causing the trouble. As to how the trouble appeared in the first place, all I know is that it seemed to start when I dragged files from Supply.scriv to Demand.scriv.
That is indeed an interesting result. There is a grey area in how a lot of the plumbing in a Mac program’s settings can be handled automatically by the system. The Recent Projects list is an example of something centrally managed in a fully automated fashion—but yeah, nothing in that list should be triggering any disk level events unless you actually select one of the projects.
We could at least try resetting preferences, to see if that is a factor or not. Of note this checklist will describe how to back up your actual settings, and restore them later. There are some project-specific things that are stored in the .plist file, but most all of it will be related to restoring the user interface and thus shouldn’t be doing anything on its own.
You will also note the checklist recommends rebooting. It is important that either that is done, or using the following shell command in Terminal: killall -u $USER cfprefsd. Skipping either of those steps may not actually flush preferences and propagate the problems into a new .plist file.
I’d be curious to see if things resolve in a factory reset state, and if not, what it then takes to get back to things being passively referenced like this.
Oh, as an aside, you may want to visit the Backup tab in Project ▸ Project Settings... for both of these projects, and locate their backup folders on the same sparseimage. It’s not quite as safe that way, but otherwise the encrypted main version is somewhat pointless if you store unencrypted copies in some central backup area like the user Library folder.
Okay, I found the error. This is indeed a “bug” in Scrivener, and is surely reproducible, but also should be easy (ish?) to fix, and in any case there’s a workaround.
The workaround is to delete favorite-projects.plist from ~/Library/Application Support/Scrivener.
The “bug” is that if a project that is stored inside a password-protected sparsebundle is referenced by favorite-projects.plist, Scrivener will try to access that project fairly often (such as when opening the Preferences pane), and when it does so the system will prompt the user for the sparsebundle password needlessly. This is a bit annoying and has some mild security implications.
To reproduce the bug:
Create a password-protected disk image.
Create a Scrivener project and store it on that image.
Mark the project as a favorite.
Close Scrivener.
Eject the disk image.
Open Scrivener.
Open preferences; or, try to view File → Favorite Projects; or, edit another project (in which case the symptom will appear sporadically).
Expected results: the “favorited” project is referenced but no attempt is made to open it.
Actual result: Scrivener accesses the favorite project such that macOS prompts for the password.
Hopefully this will be of help to others who happen to keep projects in password-protected images and then favorite them.
Ah, okay. That actually makes a bit of sense because we’re using Aliases to store the actual reference to the project in that favourites list. The advantage to using an alias is that if you move the project around (within the same original volume anyway) or rename it, the link to it won’t break.
But for these to be active entries, and to have them be verified in the list as still valid, the aliases must be unpacked and probably tested for validity, to see if the underlying resource is still present—and that is going to trigger the OS to mount any known devices necessary to test the alias.
I think the only way we could fix that is by not checking to make sure the list of projects is any good. I’m not sure if that’s a better result than what you’re running into, in the grand scheme of things. I’ll put it on the list to see if there is some way that works better for all, but I think if we didn’t verify the list then broken alias errors would be much more commonly encountered (whereas your set up is, to be fair, quite unusual).
