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

Question

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't create any symbolic links, creates aliases instead}

Answer 1

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:

1. Create file.txt.
2. Make an alias of file.txt.
3. Rename file.txt to moved.txt.
4. 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.

Answer 2

It's odd. I can reproduce it, but only if I actually check the symlink in the Get Info window in the Finder before I move the backup in. If you do all the steps without opening that window and checking, it doesn't seem to do it, but moving the original file in the Finder will make the link follow the file, but only in the Finder. Also, after relaunching the Finder, it shows the correct path, so long as the original file is still there. During all of this, the symlink doesn't change—it always points to the same place. It must be some bug with how the Finder resolves symlinks. It seems to treat them as aliases, but doesn't actually update them if you move the original file so it resets if you relaunch the Finder.

I'm not sure what the implications are, exactly. If you need to replace the original file, it's hardly practical to relaunch the Finder every time, but I guess it should only impact cases where you're opening the symlink in the Finder or perhaps programs that use the OS file chooser widget. (I didn't test if they're treated the same as the Finder)