Does creating a symbolic link to another symbolic link have any side-effects?

Does creating a symlink to another symlink on a li开发者_C百科nux box have any side effects (specifically in terms of performance)?

---

In general, no. Technically, there will be a very slight performance hit for the indirection, but it won't be noticeable to your application. As an example, most shared libraries are symlinks to symlinks (e.g. libQtCore.so -> libQtCore.so.4 -> libQtCore.so.4.7 -> libQtCore.so.4.7.1).

---

This is mostly a comment to Daniel Gallagher's argument, but it doesn't fit in the comment box, so this will make it more readable. From Wikipedia on symbolic links:

Early implementations of symbolic links stored the symbolic link information as data in regular files. The file contained the textual reference to the link’s target, and an indicator[clarification needed] denoting it as a symbolic link.

This method was slow and an inefficient use of disk-space on small systems. An improvement, called fast symlinks, allowed storage of the target path within the data structures used for storing file information on disk (inodes). This space normally stores a list of disk block addresses allocated to a file. Thus, symlinks with short target paths are accessed quickly. Systems with fast symlinks often fall back to using the original method if the target path exceeds the available inode space. The original style is retroactively termed a slow symlink. It is also used for disk compatibility with other or older versions of operating systems.

Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the path name in the link, which always requires reading additional inodes and generally requires reading other, and potentially many, directories, processing both the list of files and the inodes of each of them until it finds a match with the link's path components. Only when a link points to a file in the same directory do "fast symlinks" provide significantly better performance than other symlinks.

Thus the penalty of using symlinks to symlinks for libraries in /usr/lib is less severe than longer path lookups that perhaps even span several mount points.

I haven't seen raw numbers on the subject, but from personal experience I'd say it's at most a minor performance hit, not noticeable in most circumstances. The performance hits in combination with symlinks I've heard about (not seen in person) has been in (probably bad) implementations where system forks are used to find the target of a certain symlink.

I'd love to see "fleshier" comments concerning symlinks and performance though, since this is the second time in a couple of months that I've looked into it without coming to a definitive conclusion.

---

side effects

Yes. You can only stack so much symbolic links together before the kernel and/or application refuse to follow the chain. (Because cycle detection is costly memory-wise, especially so in the kernel, no "seen" flags are used, and instead the recursion depth is capped.)