Stop Finder from creating aliases when moving Applications

You can hold Cmd while dragging to move the .app file in El Capitan.


Do you like solving problems with terrible hacks? I like solving problems with terrible hacks.

The following will prevent this behavior on a machine running 10.13 High Sierra with System Integrity Protection disabled.


Instructions

  1. Make a new file /Library/Scripts/Fix-Applications-Folder.sh with the below contents:
#!/bin/bash

function main {
    while [[ $(pgrep Finder) -eq "" ]] ; do sleep 1 ; done
    mv /Applications /Apps
    sleep 1
    killall Finder
    sleep 1
    mv /Apps /Applications
}

main &
  1. Make the file executable: sudo chmod +x /Library/Scripts/Fix-Applications-Folder.sh

  2. Add the script as a loginhook: sudo defaults write com.apple.loginwindow LoginHook /Library/Scripts/Fix-Applications-Folder.sh

Log out and log in, and dragging apps out of /Applications will behave like any other folder on your machine.


What's happening?

This hack exploits a quirk in Finder that I discovered: If you rename the Applications folder to something else and relaunch Finder, the folder's special alias behavior will disappear—and this persists even once the folder's name has been changed back to "Applications". The effects last until the next time Finder is relaunched, which usually won't happen until you log out or reboot.

So, the above instructions create a script that automates this process, and set up a login hook to run that script any time a user logs in. The script waits for Finder to launch, then renames /Applications to /Apps and kills Finder. Once Finder has relaunched, the folder is renamed back to /Applications.


Q&A

Does this cause any side effects?

I haven't found any so far! The Applications folder retains its pretty icon, and running path to applications folder in Applescript will still return the correct result.

Does this work in other versions of Mac OS X?

I haven't tested it on Mojave or Catalina, but I suspect it will work without changes in Mojave. In Catalina, you would at minimum need to remount / as read-write; you might try adding sudo mount -uw / before the last line of the script.

This method does not work in 10.9 Mavericks, which does not exhibit the Finder quirk I described above. I don't know what will happen on 10.10–10.12, you'd have to try it.

Can I do this without disabling SIP?

Nope, and you'll need to leave SIP disabled too. The entire purpose of SIP is to prevent users from doing things like this.

Loginhooks are deprecated, why didn't you use launchd?

Loginhooks have two very useful properties:

  1. They run whenever a user logs in (not just when the system boots)
  2. They run as root.

LaunchAgents get us only #1, and LaunchDemons only #2. That said, running the script as a LaunchDemon will almost work, the only problem is when a user logs out and logs back in (or a second user logs in).

Do note that according to Apple, your machine can only have one Loginhook at a time. So on the off chance you already have a Loginhook set up for something else, you need to add the code to your existing script instead of creating a new one.

Why go through all this trouble? You can't just hold down the cmd key?

I realize I'm being a bit crazy, but this has legitimately bothered me for years. I don't like the inconsistency of it. /Applications is just a folder, and god damnit, it should behave the same way as any other folder. This comment I left on Hacker News a while back might also provide some insight into why I'm so annoyed by the behavior: https://news.ycombinator.com/item?id=20224370

Maybe no one else will use this, but I wanted to have the solution documented. (I just wish it worked on Mavericks—I'm trying to move my life to Mavericks.)