Editor: Linking to files located on the Mac


when I put a link to a local file into my text in the Scrivener editor, I observe a phenomenon that bothers me.

Dragging a file from the main Finder window into the editor produces a link in the Scrivener editor that looks like this:


This URL


is fine as long as I use Scrivener on this one computer. However, working with Dropbox I use my projects on several computers, having the files and folders synched and mirrored on them so the file structure is the same on all machines.

Opening the project on one of the computers and clicking the link will fail, as it cannot find this file id.

I have found a few workarounds, though.

In oder to get a link such as “/Users/myself/whatever folder/this file” (which would be portable) I can select the link produced, right click, edit link. In the window appearing, the actual path is shown, so I can see it is actually stored somewhere but not active when clicking the link. Now, not changing anything, but just hitting “Return” in that edit-link-window will cause the actual link to convert to the desired format!

Another possibility is not to drag the file from the main Finder window, but from the status bar below at the bottom of the Finder window. There, you can show the path of a file, and dragging the file icon from there into the Scrivener editor will produce a link that is “correct” right away, i.e. it shows the path and not a file id.

A third possibility is to drag the file icon from an open document using the icon in the title bar of that window.

Now, why is the most obvious method of dragging a file into Scrivener, in oder to produce a link, failing in this way? Is this a desired behaviour or part of the consequences of using Apple’s native editor capabilities in Scrivener? Or can this be healed in Scrivener itself, which would be marvellous … since despite knowing the limitation I tend to forget about it and link files again and again, just to see the link fail next time I use it.

By the way: The bookmark tool in Scrivener’s Inspector does it right. Regardless from where I drag the file, it ends up as a nice file path and can be used from everywhere.


Interesting, as you note this appears to be a problem with Finder itself. You can readily test the actual URL state by right-clicking on the hyperlink and choosing the “Copy Link” command from the contextual menu, and then using Edit ▸ Paste and Match Style to force the plain-text (URL) output back into the editor.

In the case of Finder drags, you get the weird non-standard internal ID system pasted into the editor. I tried using another tool (LaunchBar in this case), and got a real path to the file. I guess that’s why I’ve never encountered this before! I do link to files a lot, but I use Finder about as much as I use Chess.app. :laughing:

So my first reaction here, especially considering how Finder does different things from different areas of its UI, is that this is a bug in Finder. That kind of URL is of no use to anyone long-term, I would wager not even on the same machine—it’s surely some internal thing that is meant to be decoded before it ends up on the pasteboard. Maybe I’m wrong, but if it is intentional, I don’t understand Apple’s reasoning at all here.

Obviously something is “resolving” the link properly from this coded URL since you can edit the link and it comes up properly in the dialogue box. So the question is whether the software can intercept a system drag and modify its behaviour before the link is actually created (a lot of that stuff is indeed a bit of a black box though).

It’s hard to say whether this is a global problem, because most native third-party text editors make use of the RTFD model that you see in TextEdit, where file drags actually attach the file as a duplicated object in the RTFD package, rather than linking to the original. The only other example I found in a few quick tests was Nisus Writer Pro—and indeed they do seem to be dodging this problem somehow. So that is a hopeful sign (NWP is much like Scrivener, in that it is a heavily forked version of the stock Mac editor).

I think in that case it is a matter of context. Try dragging a file into the Synopsis field for example, which forces the pasteboard to use the plain-text variant: the raw path in this case, not even the URL. Bookmarks is going to be forcing the raw text as well rather than a rich text hyperlink.

Thanks for the report; we’ll take a look into it!

The current behaviour looks like a design choice to me. My guess is that the file-id link has this virtue: it will not break when the linked file gets moved around on your Mac. Generally speaking, that would be a virtue, not a weakness.

The OP has an exceptional use case (maintaining and sharing files between two carbon copy computers). If I am right, adapting the current behaviour to suit that case (unless somehow made optional) would make those links more fragile for almost everyone else.


That does make sense as a design intent, though it still doesn’t seem to me a good long-term solution. If the file system is perfectly maintained over years, never having to reformat or reinstall, never switching to a new Mac as the years go by, and in fact never using any method that would save the file in such a way that the original is replaced by a new version, then an abstraction like this remains useful.

Otherwise it has its own form of fragility, and one that is much more difficult to recover from in that the link itself contains no useful human-friendly information. I can’t see from an invalid ID number that this once linked to “some file that I know where it was moved to.txt” from its old path. Instead after any of the above conditions occur, all of my affected links are not only broken but made mysterious in what they even were meant to refer to in the first place.

So, some fragility there, too. But it is perhaps worth pointing out that Scrivener is, apparently, storing the path information also* — so in the event of a failure of the sort you describe, you are not left completely in the dark.


  • Both you and the OP specified ways of gaining access to this info. At least, I am assuming the path info in those cases is coming from Scrivener and not just being grabbed from the underlying system data at the time.


thank you for your thoughts on this. I can see, it may be a bug (or feature) in Finder, and Scrivener may no be able do anything about it.

I made a small experiment and linked a document by dragging it from the Finder to Scrivener, producing a “file id” link. Then I moved the document in the Finder into another folder. Now, clicking on the link in Scrivener will still open the file, so the “file id” seems to be a permanent identifier, independent of the path. Looking at the path within Scrivener, using “Edit link …” the entry field actually shows the correct new path, after moving the file.

So my conclusion is, that Scrivener resolves the path from the “file id” during clicking/runtime, it is not stored as a static path within Scrivener when the file is linked, otherwise it would still have the old path. This is supported by the observation that closing the project, moving the file once again to a third location, re-opening the project and then clicking the link, Scrivener will still find the file and open it. So … maybe we should consider this a Finder feature, not a bug.

As long as you stay on the same machine, this is an advantage. You will never loose track of your linked files, no matter where they will be placed afterwards.

The draw back is, when you have such a link and try to use it on another machine (as in my scenario), you will never be able to find out what file it is and where it is stored (apart from using the file name shown in the editor and searching for that name) … because clicking on “Edit link …” on the other machine doesn’t even show the edit window! It seems to me, Scrivener tries to resolve the “file id”, cannot find it, and then decides not to show the window at all. This could be considered a bug in Scrivener.