There is a serious bug in Finder in macOS Mojave 10.14.2 which will invariably cause it to become unresponsive. The only solution is to force the Finder to restart, and there doesn’t appear to be any generally-usable workaround.

This bug may affect earlier versions of Mojave, even of High Sierra: I welcome reports from those using older versions of macOS, please.

The bug occurs if you select a Finder Alias to a missing folder in a window set in Column view. After an initial pause of a few seconds, the spinning beachball appears, and the only way to regain access to the Finder is to press Command-Option-Escape, then select Finder and restart it.

Steps to reproduce

Open a Finder window, navigate it to a folder within Documents, and switch the window to Column view.

There, create a folder and give it a name. Then select that folder, and create a Finder Alias to it using the contextual menu or the Make Alias command in the Finder’s File menu. Once the alias has been created, put the original folder in the Trash and empty it.

Still working in Column view, select the alias to the now non-existent folder, so that you would expect to see its contents or, as it is now a broken alias, the folder alias icon.

After a few seconds, the spinning beachball appears, without any QuickLook thumbnail or other preview of the alias. The only way to recover use of the Finder is to force it to restart.

Log examination

There don’t appear to be any log entries related to the bug, nor to the Finder becoming unresponsive. I can find no evidence of these events in the unified log.

If you leave the beachball spinning long enough, a spindump will of course be generated. Examination of example spindumps doesn’t make any cause obvious.

What isn’t affected

Finder views other than Column views behave correctly when displaying broken aliases to folders, but none would be expected to show the contents if the Alias were still valid. This does provide a possible workaround if you discover that you have such an Alias and want to remove it. This may be possible even from a Column view if you select the Alias and drag it quickly out of the window and into the Trash.

It is also possible to try to open a broken Alias, eliciting the dialog offering to delete or repair it. However, cancelling out of that dialog causes the whole Finder window to be closed, which appears inappropriate behaviour, and is probably a separate bug.

The bug doesn’t affect Aliases or Bookmarks to files or to standard bundles such as RTFD, only those to regular folders for which the Finder would be expected to display their contents rather than a custom icon.

Bookmarks saved in file format by my free tool alisma may also provoke this bug, but sometimes will display an icon properly and not result in the Finder becoming unresponsive. However, Aliases created from the Finder seem always to provoke the bug.

My greatest fear was that this bug could also affect the Finder-like views used in Open and Save File dialogs in apps. However, that isn’t the case: broken Aliases to folders are handled perfectly correctly in those dialogs.

This bug doesn’t occur when resolving an Alias or Bookmark using URL.init(resolvingBookmarkData: bookmarkDataIsStale:) or URL.init(resolvingAliasFileAt:); when either of those is called (by Precize or alisma) to resolve a broken Alias or Bookmark to a folder, they correctly return errors and do not hang. The bug therefore appears to be in Finder’s code to handle such broken Aliases, possibly in that which tries to display the contents of the non-existent folder.

Possible workaround

Finder Aliases are the only form of link available to those working wholly within the GUI. Users proficient at the command line and aware of their limitations and use may find it preferable to use symbolic links to folders rather than Finder Aliases, but they don’t provide an exact equivalent by any means, and in most cases are more cumbersome to make and can’t be moved around in the way that Aliases can.

If you have experienced this bug, or cannot reproduce it in Mojave, I’d be very interested to hear from you in a comment, please.

Postscript

Thanks to Jeff @lapcatsoftware who reports that this bug isn’t present in High Sierra. It does therefore appear fresh for Mojave.

I have now filed this in a bug report with Apple.