Most of the files in my project are Aliases that I make by importing files held on my computer hard drive. Often times, however, they “lose touch” with the original files, and when I click on them in the Binder I just see a generic PDF logo in the Editor instead of seeing the specific file itself.
The User Manual says we can change the original file’s name and location on our computer without affecting the Alias, but that doesn’t seem to always be the case.
They should work (or break) equally no matter if they are stored in ~/Documents/Test.alias or ~/Documents/Your Project.scriv/Files/Docs/UUID/content.alias. To the Mac these are just two different folders. If anything an alias should be a little more robust when stored within Scrivener, as we store the original path name when you create or import one, and if it detects the alias is broken, it will do a little local searching to try and discover the file around the original location, and “heal” it if it can. Most commonly this will fix cases where the you use Dropbox with different acount names.
As noted the alias itself is resiliant to changes in Finder, but there are limits. Copying the alias to another computer for example, will break it, even if the file is there somewhere.
So to really get to the bottom of this, we’d need to know a lot more about your workflow, and what it takes in a procedural sense, to get an alias from function to broken.
Thanks for your reply. I’m not exactly sure what you mean by “~/Documents/Test.alias or ~/Documents/Your Project.scriv/Files/Docs/UUID/content.alias.” In any case, yes, the files in question are actually aliases of aliases - namely, the original file is in my Dropbox folder, but then has an alias on my desktop. I then create an alias within Scrivener (“import research files as Alias”) to the file on my desktop. Should I try to take out one of these steps?
I hope it’s clear that I’m talking about Aliases created by Scrivener, and not Aliases that I myself created outside of the program.
(A further thought: some of my file names have special characters, like asterisks. Is it possible that’s disrupting the process somehow?)
I mean that we are just using system aliases, and storing them in the project package (which is just a folder). So to the system an alias in Scrivener should be as robust as an alias on your desktop, so long as all three things (the two aliases and the original file) remain on the same system together.
Ah, in that case yes I would recommend one of two courses:
When using the import feature, target the original file, not an alias pointing to that file. I don’t know how well the system works with chains of aliases. I’ve never tried to test it as I can’t even think of a good reason to do that.
The import as aliases feature is a mere convenience in that it creates an alias for you. If you already have an alias pointing to the correct file, you can simply drop that right into the binder. The result is the same, two independent aliases, each pointing to the same file.
It’s unlikely. Aliases do their magic by referring to the file using its internal disk address, which we would never use ourselves directly (just like we don’t visit websites by typing in their physical IP address). That address doesn’t change when you rename files. That is why renaming or moving files should theoretically never be the reason an alias breaks. To look into why an alias breaks, you have to be aware of what that address means: a physical mapping related to one hard drive. So it’s when we take aliases off of a drive that they break, or if the alias points to a file on an external drive that we unplug (though the alias might “heal” when you plug it back in).
I’m not sure if your aliases are actually breaking. It could just be that once they are reloaded from scratch, the alias in Scrivener is pointing to an alias as a file, at that point, not a reference to a PDF or whatever, but an alias. So what you perceive as “broken” is just how an .alias as a file presents itself in the viewer.