6 ms·

Wait, what? Is he saying symlinks are bad? I like symlinks.

by metabrew 15y ago

davidw 15y ago
He's saying "get off my lawn". And he has earned the right to do so.
- sp332 15y ago
  He didn't just say that, he headed up the Plan9 project to fix it. https://secure.wikimedia.org/wikipedia/en/wiki/Plan_9_from_Bell_Labs#File_systems.2C_files_and_names https://secure.wikimedia.org/wikipedia/en/wiki/Plan_9_from_B...
eterps 15y ago
He said they weren't added with proper appreciation of the Unix model and its simplifications. So he could mean that symlinks can be implemented in a more Unixy way?
- saljam 15y ago
  Probably, c.f. bind and union mounts .
dtf 15y ago
"Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file." http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames
- reinhardt 15y ago
  Doesn't this specific criticism hold for hard links too?
  - lyso 15y ago
    It's mitigated in that you can't hard link a directory (except in recent MacOS). So I suppose you would always know the real cwd of your shell, for instance.
    - protomyth 15y ago
      adding OS X hard link discussion: http://stackoverflow.com/questions/80875/what-is-the-bash-command-to-create-a-hardlink-to-a-directory-in-os-x http://stackoverflow.com/questions/80875/what-is-the-bash-co...
- uriel 15y ago
  There are other problems with symlinks too: http://harmful.cat-v.org/software/symlinks http://harmful.cat-v.org/software/symlinks Every command that operates on files needs an extra flag to tell it whatever it should follow symlinks, or operate on the target, or on the symlink itself, etc.
  - mansr 15y ago
    Only commands capable of doing something meaningful with symlinks need such a flag. These are a minority.
    - uriel 15y ago
      Any program that manipulates or traverses file trees is affected, and a few more, in an OS that is built around the concept of hierarchical file systems, this is quite a few.
- barrkel 15y ago
  That's rather the point. When presenting a view of the file system under some particular directory, it's nice to not have to hard-link every file into place, and instead include wholesale directory trees. That's my most common use case for symlinks.
deleted 15y ago
[deleted]
jgrahamc 15y ago
I can understand why he wouldn't like symlinks. They weren't introduced until 4.2BSD and they seem like a bit of a hack. Compare them to hard links. If you move the destination file the hard link remains, but the symlink is broken and there's no simple way to figure out where the destination file was mved to. Also hard links include reference counting so you know that someone is pointing to your file. Not so with symlinks. Also, hard links mirror the permissions of symlinks. Note that the history shows up in the ln command which originally only created hard links, and then got the -s parameter when symlinks were introduced.
- praptak 15y ago
  Also, symlinks create a concurrency hell of their own: http://en.wikipedia.org/wiki/Symlink_race http://en.wikipedia.org/wiki/Symlink_race
- Roboprog 15y ago
  Could be worse. Could be Windows desktop shortcuts. Fuzzy logic of target resolution? Now that's messy. Symlinks may be ugly and/or dangerous relative to the original file system concept, but they solve problems. They are not "all good", but life would be worse without them. E.g. - application by application implementation of location aliases a la IIS virual directories (or whatever they called it) for web applications.
- billswift 15y ago
  I tried using hard links back in the late nineties when I was new to linux. Instead of creating a second link to the file it copied the file to the new directory. I discovered the problem when I modified one copy and found the second copy, which was supposed to be a hard link, wasn't changed. I don't know what went wrong, but with symlinks available, I just never bothered trying hard links again. ADDED: Note that I avoided hard links after that, because I was worried about what would happen if I modified one file and deleted it, thinking it was a link to another, when it was actually a copy. A person could lose a lot of work if that happened. At least with a symlink, I know that something is or is not a link.
  - 15y ago
DanBC 15y ago
(http://www.usenix.org/events/usenix2000/general/pikelex.html http://www.usenix.org/events/usenix2000/general/pikelex.html) >Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem. etc etc. filesystems are a mess, and it'd be great if something could fix them.
saljam 15y ago
Symlinks are bad. They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph. What happens if you move a symlink? Will it still point to the same object? That depends on whether it's relative or absolute. What if you move the directory containing it? Do you have to recursively check for the correctness of links every time you operate on a directory? Sounds unreasonable to me... What if it links to a location which isn't mounted? Whats the definition of '..'? If you cd into a linked directory and do an 'ls ..', should that list the parent of the target or the link? How would you implement that? The point is, symlinks are a messy kluge which probably wasn't thought out very well. You can look at what Rob Pike has to say about it himself on http://cm.bell-labs.com/sys/doc/lexnames.html http://cm.bell-labs.com/sys/doc/lexnames.html
- runn1ng 15y ago
  Uhhh.... yeah, but that's the point. You have file at /some/path, then you put newer version of that file to /some/path, replacing the old file, and the symlink still points at the same address, and it doesn't matter what actually happened with the file itself. It's useful enough to warrant its own abstraction.
  - runn1ng 15y ago
    (I will add I don't know how Plan 9 did this, since I never really touched the system)
- Locke1689 15y ago
  They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph. What you mean to say here is that it was a DAG and now it's a directed graph.
dextorious 15y ago
Yes, but have you considered the ALTERNATIVES? (that is, not only "not having anything like them").

Wait, what? Is he saying symlinks are bad? I like symlinks.

davidw 15y ago

He's saying "get off my lawn". And he has earned the right to do so.

sp332 15y ago
He didn't just say that, he headed up the Plan9 project to fix it. https://secure.wikimedia.org/wikipedia/en/wiki/Plan_9_from_Bell_Labs#File_systems.2C_files_and_names https://secure.wikimedia.org/wikipedia/en/wiki/Plan_9_from_B...

eterps 15y ago

He said they weren't added with proper appreciation of the Unix model and its simplifications. So he could mean that symlinks can be implemented in a more Unixy way?

saljam 15y ago
Probably, c.f. bind and union mounts .

dtf 15y ago

"Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file." http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames

reinhardt 15y ago
Doesn't this specific criticism hold for hard links too?
- lyso 15y ago
  It's mitigated in that you can't hard link a directory (except in recent MacOS). So I suppose you would always know the real cwd of your shell, for instance.
  - protomyth 15y ago
    adding OS X hard link discussion: http://stackoverflow.com/questions/80875/what-is-the-bash-command-to-create-a-hardlink-to-a-directory-in-os-x http://stackoverflow.com/questions/80875/what-is-the-bash-co...
uriel 15y ago
There are other problems with symlinks too: http://harmful.cat-v.org/software/symlinks http://harmful.cat-v.org/software/symlinks Every command that operates on files needs an extra flag to tell it whatever it should follow symlinks, or operate on the target, or on the symlink itself, etc.
- mansr 15y ago
  Only commands capable of doing something meaningful with symlinks need such a flag. These are a minority.
  - uriel 15y ago
    Any program that manipulates or traverses file trees is affected, and a few more, in an OS that is built around the concept of hierarchical file systems, this is quite a few.
barrkel 15y ago
That's rather the point. When presenting a view of the file system under some particular directory, it's nice to not have to hard-link every file into place, and instead include wholesale directory trees. That's my most common use case for symlinks.

deleted 15y ago

[deleted]

jgrahamc 15y ago

I can understand why he wouldn't like symlinks. They weren't introduced until 4.2BSD and they seem like a bit of a hack. Compare them to hard links. If you move the destination file the hard link remains, but the symlink is broken and there's no simple way to figure out where the destination file was mved to. Also hard links include reference counting so you know that someone is pointing to your file. Not so with symlinks. Also, hard links mirror the permissions of symlinks. Note that the history shows up in the ln command which originally only created hard links, and then got the -s parameter when symlinks were introduced.

praptak 15y ago
Also, symlinks create a concurrency hell of their own: http://en.wikipedia.org/wiki/Symlink_race http://en.wikipedia.org/wiki/Symlink_race
Roboprog 15y ago
Could be worse. Could be Windows desktop shortcuts. Fuzzy logic of target resolution? Now that's messy. Symlinks may be ugly and/or dangerous relative to the original file system concept, but they solve problems. They are not "all good", but life would be worse without them. E.g. - application by application implementation of location aliases a la IIS virual directories (or whatever they called it) for web applications.
billswift 15y ago
I tried using hard links back in the late nineties when I was new to linux. Instead of creating a second link to the file it copied the file to the new directory. I discovered the problem when I modified one copy and found the second copy, which was supposed to be a hard link, wasn't changed. I don't know what went wrong, but with symlinks available, I just never bothered trying hard links again. ADDED: Note that I avoided hard links after that, because I was worried about what would happen if I modified one file and deleted it, thinking it was a link to another, when it was actually a copy. A person could lose a lot of work if that happened. At least with a symlink, I know that something is or is not a link.
- 15y ago

DanBC 15y ago

(http://www.usenix.org/events/usenix2000/general/pikelex.html http://www.usenix.org/events/usenix2000/general/pikelex.html) >Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem. etc etc. filesystems are a mess, and it'd be great if something could fix them.

saljam 15y ago

Symlinks are bad. They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph. What happens if you move a symlink? Will it still point to the same object? That depends on whether it's relative or absolute. What if you move the directory containing it? Do you have to recursively check for the correctness of links every time you operate on a directory? Sounds unreasonable to me... What if it links to a location which isn't mounted? Whats the definition of '..'? If you cd into a linked directory and do an 'ls ..', should that list the parent of the target or the link? How would you implement that? The point is, symlinks are a messy kluge which probably wasn't thought out very well. You can look at what Rob Pike has to say about it himself on http://cm.bell-labs.com/sys/doc/lexnames.html http://cm.bell-labs.com/sys/doc/lexnames.html

runn1ng 15y ago
Uhhh.... yeah, but that's the point. You have file at /some/path, then you put newer version of that file to /some/path, replacing the old file, and the symlink still points at the same address, and it doesn't matter what actually happened with the file itself. It's useful enough to warrant its own abstraction.
- runn1ng 15y ago
  (I will add I don't know how Plan 9 did this, since I never really touched the system)
Locke1689 15y ago
They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph. What you mean to say here is that it was a DAG and now it's a directed graph.

dextorious 15y ago

Yes, but have you considered the ALTERNATIVES? (that is, not only "not having anything like them").