Finder treating symbolic links differently than terminal MacBook Pro Retina OS X 10.9.4 I created symbolic link jboss7 for hard link jboss-as-7.1.1.Final-downloaded and it worked fine in Finder. Then I made backup before modifying JBoss...



ln -s jboss-as-7.1.1.Final-downloaded jboss7
cp jboss-as-7.1.1.Final-downloaded jboss-as-7.1.1.Final-downloaded-orig


Later, I renamed the hard link to jboss-as-7.1.1.Final-downloaded-modified and replaced it with backup.

mv jboss-as-7.1.1.Final-downloaded jboss-as-7.1.1.Final-downloaded-modified
mv jboss-as-7.1.1.Final-downloaded-orig jboss-as-7.1.1.Final-downloaded


The symbolic link properly points to the backup with the same filename (ending with -downloaded), but Finder shows and treats the symbolic link incorrectly, saying it is alias for folder ending with (-downloaded-modified).

Is Finder supposed to treat symbolic links in this manner? How do I update Finder to recognize the symbolic link as point to the current hard link?

Side point: commands I wrote using tcsh terminal or Finder (don't remember, and terminal history does not go far enough back to answer this).

Related: OS X won&#39;t create any symbolic links, creates aliases instead
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.