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.
I’m planning to move a lot of files to a NAS. I know that macOS will actually create new files with new IDs and obviously the filepaths will also change.
I have 400 hook links in various documents pointing to these files.
I’ve read the method above to generate a new ID and insert it in the comments. That seems quite painstaking to do for each file. So my question is:
Is there a way to automate this process?
Or
Is there a way to batch change the encrypted path parts of all my hook links? Maybe even by using find and replace on a file in the sync folder in the cloud?
I’m just a little worried of if a couple of years down the line I move these files again and the hook links have grown to thousands.
Any help or different ways to look at this problem is appreciated.
Shane
There’s no need to manually manage IDs. Hook will figure out the mapping as long as when you move the files over to the new location, they have same relative path information. If you have several hooked files with the same terminal filename, then Hook will favor the file that has the longest matching path for it, from end of the pathname backwards. When you initially open a hook://file/ URL from outside Hook and Hook finds several matches you’ll get to choose.
Be sure to index the new folder or drive with Spotlight. If the files are duplicated somewhere else on your system and you don’t want them hooked (e.g., they are in a backup folder), then initially exclude them from Spotlight until Hook has had a chance to index them. Hook relies on spotlight when its own indexing fails to find a file.
this may be relevant How to Backup and Restore Hook Data – Hook
2022-02-04 7:58 PM PT. Clarified my first “Spotlight” sentence
Hi Luc,
Thanks so much for your reply. I’ll move a batch of files on Monday, make sure to delete the old files from their current location and let spotlight index them in their new home on the NAS and and let you know.
Shane
Hi again.
So I’m halfway there with the problem. I did what you suggested, moved a bunch of files to the Network Attached Server, deleted them from my hard disk and got Spotlight to index the NAS.
But when I clicked the hook links, I was getting a permissions error. This was because the files were still in the trash, once I emptied the trash I no longer got these errors but now when I click on the links nothing happens.
So instead of clicking on the link, I tried using Find within the hook app to see if that worked. But, strangely as soon as I open the find part, hook crashes. I tried this lots of times on three computers. This never happened before. I sent a couple of crash reports when the hook app asked me, the last one was today 8th February at 16:54 Spain time.
Sorry for the trouble.
Just want to make sure, could you please tell us your macOS version?
Hi, yes of course. On one computer it’s 10.15.7 and on the other it’s 10.13.6
Maybe the problem is unrelated to my moving files to the NAS and re-indexing.
This is unrelated to move. There’s an issue with Hook’s search that was introduced in latest Hook update. It only affects users with versions of macOS prior to Big Sur. We ran into a deep bug in macOS that got missed in our testing.
Ah, OK. That’s good to know. I don’t use the find function much anyway. So what do you suggest as the next step to re-link the files? I have recreated the nested folders two deep to help hook recognize them. I.e. if the original places was Users>Home folder>Dropbox >Database, the moved file lives in Servername>Dropbox>Database. Is this enough for the links to heal?
Also to force spotlight to re-index the server, I used the way Apple suggest-adding the server folder into spotlight ‘s list of where NOT to index and then removing it again. There is no indication of how long it takes to re-index again but I checked back the next day and it still wasn’t working.
Any ideas on how to resolve this matter?
Sorry, I should have clued in when you said network drive. In Hook 3.3.2, we introduced a search scope parameter. The default is “local” per release notes..
Please do this in /Applications/Utilities/Terminal app:
defaults write com.cogsciapps.hook hfile.url.search.scope network
(We’ll create an Advanced Preferences tab and more UX scaffolding.)
It worked! Thank you so much. It’s really heartening to know that if files get moved to a new volume, Hook will search for them again like this. Actually for the benefit of anyone else having this problem in the future, there are three steps that you need to take:
1 Make sure the original file is not in the trash or Hook will throw up a permissions error
2 The volume has Apple File Protocol selected. I had both SMB and AFP both selected but on some forums they recommend turning off SMB
3 As Luc suggested, type the above command into Terminal