file links in Inspector → External bookmarks are not robust

Applications like Hook hookproductivity.com/ ( a link manager) create robust file links. You can change the directory name, the filename etc and the link will not break. I use Hook many times a day and it works flawlessly. The downside is that my links are hook proprietary and if they go out of business I am cooked.

As far as I understand (and tested), Scrivener inspector → external bookmark → file break when the name of the file or the is changed. The fact that Hook links work means that the possibility exists of some kind of unique file UUID akin to Bear or Evernote note UUIDs. You can move Bear or Evernote notes around and links to those notes still work.

I can’t understand why, in this day and age, and will apps as sophisticated as Scrivener, this is not the standard for file links, which assume that the general file/folder configuration will remain static until the end of times.

thanks in advance for your feedbacks

Hook creates UUIDs when you create a “hook” to a file. That’s why they are proprietary, There is no such capability built in to the Mac OS file system.

Scrivener uses UUIDs for the component files of the project itself, but does not do so for external bookmarks. OTOH, there’s no reason why you couldn’t point the bookmark at a Hook-created link.

Katherine

As far as I understand it, the sort of link that Hook creates has two layers. There is the internal layer it uses itself, and then there is the external interface which talks to the target software. So while the manipulation of links and such within the Hook system of data won’t break its internal links, it is still ultimately dependent upon Scrivener’s external link facility in order to connect with the binder item inside the project you’re linking to. It of course has no other way of causing Scrivener to open a project and load a specific binder item.

That is mainly down to the difference in philosophy between how data is saved. A Scrivener project (which is all by itself a thing neither of those tools really support as I understand it), is more like a .docx file. It’s saved to the file system in an accessible location, and that in effect becomes a form of user interface that is open-ended. You can choose from thousands of different tools to manage your work, you don’t need special plug-ins to be designed in order to search for a piece of data, you can store your data on any technology that understand files, like a tape drive backup or a remote server like git, etc.

The downside is of course that without a simple way to exert total management at the software level, there is no good way to say “1A3137CC-AA63-4329-BBAC-352E096CCFA6” = “/Users/youraccount/Documents/SomeFile.scriv” in a way that can magically become another path, if you go into Terminal and execute a command that renames SomeFile.scriv. So if a there is no way to form an abstraction like that into a URL, then it must use the file’s address—and that is then something you have to manage in order to keep coherent.

It’s not that the software assumes anything, or that this has anything to do with sophistication, that is simply how paths work and is fundamental to your entire operating system. I’m not sure what you’re expecting software to do here. Preview is not responsible for where you store your PDF files. Photoshop is not responsible for your PSD files.

There are management tools that you can use to get around some of those problems. Aliases are one of them, they have a way of treating file system objects in a manner similar to a managed database. We even make use of them in some cases (the File ▸ Favorite Projects mechanism stores alias links to the project, for example)—but if you’re going to be using URLs and file paths to references files, again, it’s up to you to keep your system coherent.

Katherine and Ioa: thank you both very much for your most intelligent and instructive answers.

Hello Katherine. just in case you would be interested: sophisticated programmers have suggested to me that they may be using inodes and a database intermediary between the inodes and conventional file paths.

grymoire.com/Unix/Inodes.html