3

From the user point of view, for the purposes of file content, symbolic link is the same as the target file:

Symbolic links operate transparently for most operations: programs that read or write to files named by a symbolic link will behave as if operating directly on the target file.

However, it appears that there are situations when a symbolic link cannot be used instead of the actual file (Symbolic links to icns files are ignored on Mac OS X).

Are there any other examples in more conventional unixes?

Specifically, are there situations when a symbolic link cannot be used instead of the actual file?

The aspects I am aware of (and thus not interested in) are:

  1. Of course, there are many examples of unix commands distinguishing symlinks from their targets (ls, stat, find &c). However, these commands deal with files as file-system objects, not their contents.
  2. Other examples include security measures (e.g., ftp or apache refusing to get a link to a file outside the tree).
  3. Still more examples can be invented using "power tools" (e.g., emacs can behave differently depending on whether called on a symbolic link).
  4. A developer can, of course, easily distinguish between files and links - and thus screw the user over. So, when did they actually screw the user (for no good reason, like with the Mac icons above)?

closed as too broad by goldilocks, jasonwryan, derobert, Anthon, Ramesh Dec 8 '14 at 17:53

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Those situations where symlinks are actively rejected usually have to do with security concerns. E.g. apache will by default refuse to serve symlinks as web content, because you could construct a symlink to a file that only the apache process is allowed to read, and then request that symlink via HTTP, bypassing the security. – wurtel Dec 8 '14 at 15:42
  • 3
    At a lower level (C API), there is always a way to distinguish a link from a file, either by a flag (O_NOFOLLOW) or by a different set of functions for each type (stat / lstat). For this reason, the decision of whether or not a link should be treated transparently belongs to the developer, and can therefore vary from one application to another, without any specific kind of "rule" to be applied. – John WH Smith Dec 8 '14 at 16:05
  • Dropbox would be an example. It requires the folder to be named Dropbox and actually be a folder. – muru Dec 8 '14 at 16:38
  • This is 100% application dependent, i.e., there's no rule. As J. Smith already pointed out. – goldilocks Dec 8 '14 at 16:40
  • @goldilocks: apps can do that, yes, but the question is about system-imposed restrictions. – sds Dec 8 '14 at 16:48
0

You should not move any directory pertaining to a Solaris package to a different directory then use a symbolic link to fix the path.

While it will work initially, as soon as you install either a patch or a new package that share some part of the previous pakage path, the symbolic link will be removed and replaced by a plain directory by the Solaris package management commands.

Not the answer you're looking for? Browse other questions tagged or ask your own question.