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
Best Answer
I was able to reproduce this as well (on OS X 10.9.4). A simpler case is as follows:
If the Finder was open to the working directory while
mv
was executed, then it will (incorrectly) followlink.txt
tomoved.txt
until it is restarted. Interestingly, you don't even need the Terminal to reproduce this bug, since it also applies to aliases:file.txt
.file.txt
.file.txt
tomoved.txt
.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.