"Failed to Enable Personal Hotspot on iPhone" – finally, a solution

Some of my older Macs running High Sierra or Mojave were unable to join the Personal Hotspot of one or even two of my iPhones.

I searched the Apple "Community" Support forums and found several related questions, with lots of "I have the same issue" tags, but with no helpful answer:

• https://discussions.apple.com/thread/8153026
• https://discussions.apple.com/thread/8337291
• https://discussions.apple.com/thread/254471591

So I did figure this out on my own.

If you get this error when trying to connect from your Mac to the Personal Hotspot of your iPhone, try the following for a fix:

 There is a file called "com.apple.airport.preferences.plist" in the folder "/Library/Preferences/SystemConfiguration".

 If you cannot locate it directly, use a tool to find it, e.g. with my program Find Any File (no need to pay for it if you only use it once - just download it).

Then make a back-up of the file, in case you get it wrong below! For instance, copy the file to your Desktop.

Then you have two options:

1. Delete this file. But that will also reset all your network interfaces, e.g. if you had set up a LAN connection with a fixed IP address or made other configurations in the System Preferences' Network panel. And after deleting it, you need to restart the Mac so that it sets up the network interfaces again. Then try to connect to the phone again.
2. If you're more adept, edit the file, e.g. with the app PrefEdit or BBEdit, then find all entries that mention "phone", and remove those. After saving the changes, you should be able to reconnect to the phone without even requiring a restart.

If something went wrong, copy the backed-up file back into the folder (you'll have to enter your admin password).

Good luck!

What I did in the past 2 years, programming related

I had stopped to blog here in 2019 because I wasn't too happy with the blogging platform I'm using (Blogger). I was looking for alternatives, but with the constraint that I'd be able to keep the existing blog posts, along with their sometimes valuable comments. I gave Wordpress a few attempts but am not too happy with its complexity and rather frequently discovered new vulnerabilities. I also considered Jekyll, which is nice but can't do comments.

So for now, I'm just staying with Blogger until it dies on its own, probably.

So, here's a brief summary of things I did the past two years I thought of blogging about, but didn't because I was all this time waiting for a better blogging system to come to me.

Excel Diff

I needed to be able to visualize differences when comparing Excel spreadsheets.

I worked with the premise that tables in the sheets have a column or row with an identifying key, and then I compare those with identical keys, even if they had been moved around between the compared versions, identifying which rows & columns got removed or added, and which cells got changed. It's fairly usable for that kind of data.

Here's an example:

I had considered making it public and selling it, but so far the interest seemed to be rather small, so I didn't ever make the effort.

If you, as a programmer, are interested in taking over this project, and if you are familiar with the Xojo development system, contact me.

Repair .textClipping, .webloc and related files restored from git

I store a lot of information in a "Info" folder inside my Documents folder. As I have several computers in use, I like to have those files present on all Macs, and in sync. I don't like using iCloud's automatic sync service for this, so I decided to simply store it all in a git repository.

The problem with git is that it's not made to store arbitrary file data but is mainly meant for plain text files. And because of this, git won't store resource forks and Mac specific metadata.

This led to the effect that many of the older .textClipping and .webloc files I had in that folder did not restore with any data on the other Macs because the had their information in the resource fork, which didn't transport over.

But there is a way to work around this: Modern macOS versions store the information for .textClipping and .webloc in their data fork.

So I wrote a program that would scan a folder for files that were still using the resource fork for data storage, and copy the data over to the data fork. And it does the same in the opposite way as well: It copies the data fork's contents back to the resource fork as well. That's mainly needed to make QuickLook work with .textClipping files (apparently, Apple's QuickLook code has not been updated to look for the text clipping data in the now-preferred data fork, yet).

Finally, the tool also identifies restored Finder Alias files that don't work any more because the information that the file is an Alias got lost in the git operation.

If you're interested in trying this tool, contact me. I still need to get some feedback to gather how well it works for others before I'd release it into the wild.

utis.cc

I set up a website that's supposed to be a central landing point for all things related Unified Type Identifiers. It currently points to two projects:

• nspasteboard.org (Identifying and Handling Transient or Special Data on the Clipboard)
• DotPathsFileSpec (".paths" file extension format for storing and exchanging lists of file references), see also next chapter

The .paths file format

In my program Find Any File, which, after a search you perform, lists a bunch of files and folders, I added the option to save that list to a text file. Initially I thought to just write them to a .txt file, but then I thought: Wait, other apps may want to read that file too, and use it as input for more operations on such files. I also realized that other file search programs have a similar needs. So I contacted the author of Scherlokk and proposed to use an easily interchangeable file format. That program used a plist format at that time, so he could also store metadata with it, but he agreed on my proposal to use a plain text file, and we then came up with a method to keep adding metadata, by using the JSON format.

The result is the .paths file specification .

The idea is that a file with the specific .paths  file extension means that it contains a list of file paths, and any app that opens such a file should read the paths in the file and treat them as input files for whatever the program performs with a bunch of given files.

If you are a developer or a user who thinks it would be beneficial to a macOS app to process such a file list as input, or save a given list to a file, please adopt this specification or suggest it to its developer. If you don't need to add metadata, then it's practically nothing more than a bunch of POSIX paths, separated by LFs (or NULs, if you prefer).

Also note that this is the easiest way to pass a bunch of paths that are output by command line tools, even if they're in the 1000s, as passing that large number of paths via the "odoc" AppleEvent (such as via the Terminal command  open ) will not work.

Be aware of NSDockTilePlugIn collisions

Just a quick heads-up: If you are a developer who includes a Dock Tile Plugin in their app, please make sure that your NSPrincipalClass is not DockTilePlugIn! Because, if it is, and there is another app also providing a Dock Tile Plugin, they're likely to clash when loaded by the Dock, as the Dock does not, as one might expect, use the plugin's bundle ID to separate and identify the plugins. Instead, they may end up sharing the same space (especially in macOS 10.14 and earlier, where they even share the same process) and one of them will overpower the other, making the other not work.

So, always make sure to use unique class names for any type of plugin. Apple recommends using three-letter prefixes as namespaces in ObjC, for instance (which may still clash with other plugins if they use the same, so you better integrated your app's name or something more unique into all your own class names in a plugin).

Find Any File

My most popular program has gotten quite a few notable improvements in the past two years:

• Integration with PopClip, Alfred and Keyboard Maestro.
• Can save and re-open results saved to ".paths" files.
• Supports searching for Tags, inodes, Date Last Opened, Date Added.
• Can ignore diacritics in searches (e.g. that even é is found when searching for e)
• And just now in the works: Scripting! Write your own search rules in Lua or JavaScript (requires v2.3.3, which is currently in beta).

Comments?

If you have comments or questions, write them below or on Twitter (I'm @tempelorg).