Terminal – Overcoming Issue of ‘Cannot CD into Alias’ in Finder

aliasfinderterminal

I have two aliases in my home directory: devbootcamp and bookshelf. I can cd into devbootcamp but not bookshelf but I'm not sure why. I don't remember how I made the alias to devbootcamp but I followed this tutorial to create the bookshelf alias. Also strangly in my terminal devbootcamp is purple but bookshelf is not. How do I make it so they have the same functionality?

Best Answer

If you are trying to cd into an alias, it will not work; this is by design as an alias works at the Finder level, not the underlying UNIX level.

I have excerpted some of the key aspects of aliases, symbolic links (symlinks), and hard links from the article "What Are Aliases, Symbolic Links, and Hard Links in Mac OS X?" below.

Aliases

This type of shortcut is the oldest for the Mac; its roots go all the way back to System 7. Aliases are created and managed at the Finder level, which means that if you're using Terminal or a non-Mac application, such as many UNIX apps and utilities, an alias won't work. OS X seems to see aliases as small data files, which they are, but it doesn't know how to interpret the information they contain.

Symbolic Links

This type of shortcut is part of UNIX and Linux file systems. Because OS X is built on top of UNIX, it fully supports symbolic links. Symbolic links are similar to aliases in that they are small files that contain the pathname to the original object. But unlike aliases, symbolic links don't contain the inode name of the object. If you move the object to a different location, the symbolic link will be broken, and the system won't be able to find the object.

Hard Links

Like symbolic links, hard links are part of the underlying UNIX file system. Hard links are small files that, like aliases, contain the original item's inode name. But unlike aliases and symbolic links, hard links don't contain the pathname to the original object. You would typically use a hard link when you want a single file object to appear in multiple places. Unlike with aliases and symbolic links, you can't delete the original hard-linked object from the file system without first removing all hard links to it.

What works in both Terminal & Finder

Just create a symlink in Terminal

ln -s <path to some folder> <destination of link>

For example, on my Desktop, I created a symlink to my /Volumes folder

ln -s /Volumes /Users/allan/Desktop/Volumes

On my Desktop, I got this icon automagically:

You can even give it a different name:

ln -s /Volumes /Users/allan/Desktop/Stuff

And automagically...

Related Solutions

MacOS Filesystem – Understanding the Alias Filesize in Mountain Lion

Since Lion, in addition to storing Retina icons, it seems that an alias stores its many different sizes of icons in both the data and the resource fork (the xattr com.apple.ResourceFork). Possibly in a move away from Resource forks, while still supporting previous OSes (for now).

The alias I just created contained the follow formats: is32, s8mk, ic11, il32, l8mk, ic12, ic07, ic13, ic08, ic14, ic09, ic10

They are described here: http://en.wikipedia.org/wiki/Apple_Icon_Image_format

MacOS – Finder treating symbolic links differently than terminal MacBook Pro Retina OS X 10.9.4

I was able to reproduce this as well (on OS X 10.9.4). A simpler case is as follows:

touch file.txt
ln -s file.txt link.txt
mv file.txt moved.txt
touch file.txt

If the Finder was open to the working directory while mv was executed, then it will (incorrectly) follow link.txt to moved.txt until it is restarted. Interestingly, you don't even need the Terminal to reproduce this bug, since it also applies to aliases:

Create file.txt.
Make an alias of file.txt.
Rename file.txt to moved.txt.
Create a new file also called file.txt.

The desired behaviour for aliases is to point to the moved file (moved.txt) unless a new file has been created in the original location (file.txt, created in Step 4). But the actual behaviour is just like in your example: Finder continues to follow the alias to the moved location until it is restarted.

This is a bug in the Finder. The workaround is to relaunch the Finder if an open window shows a symlink/alias while you move or rename the target file.