My current setup is that I have a folder called “Writing”, and within this folder I have a number of Scrivener project folders: “X.scriv”, “Y.scriv”, etc…
Occasionally I need to save or create an image and include that within one of my projects. So naturally I open up the folder for the project I’m interested in, say, the “X.scriv” folder, and create a new folder called “Media” and save the image there.
Then I try to add the image to my project, and…
I can’t understand a reason for this. Even if I was importing a file from within one of the standard Scrivener subfolders (like “\Files”), I can’t guess why it might be disallowed. But importing from a subfolder I created, just as a useful place to store data associated with that project - why is that banned?
As with most of my problems with Scrivener this is a minor inconvenience, but is no the less annoying for that. Would appreciate any insight, or if anyone has a good way around this so I can conveniently store my data alongside the rest of the project.
People with more technical knowledge of the program will hopefully give more detail, but my understanding is that Scrivener’s organizational skills depend on a very precise internal structure. If we as users try to alter that structure, sooner or later the program will complain. In this case, perhaps this procedure creates an internal recursion, a kind of infinite regress, that the program must prevent.
I also use a folder called “Writing,” and within it I have various subfolders related to specific projects. For instance, I have a subfolder Writing\Weavings (Weavings being a journal I write for). Within \Writing\Weavings, I have some .scriv folders (e.g., “Weavings 2016-2017.scriv”). But then I have other materials in Writing\Weavings, including media, theme statements, author guidelines, etc. These are available for import into a Scrivener project without difficulty, while still remaining connected to a specific project. This enables me to keep organized, but lets Scrivener manage its own folder and internal materials as it needs to.
Obviously there are lots of ways to organize work, but it may be best to keep .scriv folders free of extraneous (from the program’s viewpoint) items.
To say it in a different way…
A Scrivener project folder (name ending in .scriv) is essentially a database comprised of multiple subfolders and numerous files. Interacting with what is inside the project folder, except from within Scrivener itself, is not recommended and risks causing problems. So they’ve presumably coded to discourage and try to protect against such.
On Mac OS X, things look a bit different, but the same holds true. Project folders are set as “packages”, which results in hiding the details/internals of the folder from the user (and presumably other apps) and instead presenting the folder as if it is a single thing, unless one goes out of one’s way to dig into the “package” internals. Unfortunately, Windows apparently doesn’t offer such a capability (“package” means something different in Windows).