What happens when a file moves?

So I’m using Hook to relate source files in Xcode to URLs related to what the source is doing (e.g. Apple docs).

It just occurred to me that I often refactor source and sometimes rename classes. If I do that is Hook going to orphan those links I’ve made? Or will it be able to keep track?

Hook links to files are designed to be resilient to being moved and renamed and refactored, but there are limitations.

Hook uses both file path and file reference to maintain links to files.

The file reference is a persistent system UUID which Hook uses to link to a file even if it is renamed and moved around. So if you rename a file in Xcode or move the project folder around, links won’t be broken.

A file reference can be broken if a file is deleted and recreated. Some applications (not Xcode) do this when they save a file, replacing instead of amending existing files. So Hook uses file path to maintain links in case a file’s reference changes.

The only time you should expect links to break is if something happens to simutaneously delete a file and recreate it with a new name.

E.g. if you move a file (⌘drag) to a different drive or partition it changes the path and technically creates a new file, with a new reference, which Hook will not recognize as the same.

Or using git to check out a commit which changes the name of a file. Git handles that by deleting the old file and creating a new file with the new name, instead of just renaming the existing file.

Aside from those cases though, Hook links are very reliable. Refactoring source and renaming classes in Xcode, as you describe, is no problem. Even git is fine in 99% of cases, its only a problem when an operation changes the path and the file reference of a file at the same time.

Thanks Graham.

If this should happen, can it be detected? i.e. does Hook sense that it’s linking to missing files? And can it be fixed, e.g. by re-linking to the new file location manually?

Thanks.

Matt

Hook does not currently provide an indication of orphaned links. If Hook cannot find the destination of a link to a file associated with the current item, it does not display the link in the Hook window (in the future, we could provide an option /command to show orphaned links with distinct formatting-- though I think normally this is not desired/required). When one side of a link goes missing, Hook tries to recover. It has several heuristics for this, which is an interesting area in which we continue to invest. (Compare: Apple enhances its aliases from time to time.) So any limitations encountered today (such as the one Graham mentioned) will not necessarily be there tomorrow. Keep in mind that sometimes files are deleted. And if the destination is not available because , say, the volume is not currently mounted, the destination may re-appear later, and will be displayed in the Hook window next time Hook is invoked on items linked to said destination.

Hook links can be used like Finder aliases, but they are somewhat more robust than Finder aliases. And of course, unlike aliases , links returned by Hook (and presented in the Hook window or inserted in .hook files) can have arbitrary resource schemes, not just pointing to files. E.g., Hook can associate with the current resource OmniFocus:// tasks.

If you are concerned that a particular link might break, you can use Search links. Just generate an ID and insert it in a comment in the file itself. This can also be used for connecting to documents of apps that lack automation but are indexed by Spotlight.