Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Symlinks are great from a "just make it work!" point of view but they're absolutely terrible from a "make it robust, sane and secure" point of view.

All of the points in the article are valid but there's even simpler stuff like the fact that you can't canonicalise paths (resolve ..) without reading the filesystem.

This should be required reading: https://9p.io/sys/doc/lexnames.html



You can resolve some .. components without reading the filesystem and there are situations where it is useful to do that, while refusing to treat .. that cannot be resolved without accessing the filesystem.

One example is inside the implementation of a function that calculates relative paths:

  1> (rel-path "a/b" "../c")
  "../../../c"
  2> (rel-path "../c" "a/b")
  ** rel-path: from path uses .. to escape common prefix: "../c" "a/b"
  ** during evaluation at expr-2:1 of form (rel-path "../c" "a/b")
The relative path from ../c to a/b cannot be calculated as a pure function of just the two strings, because we do not know what the current directory is called in the .. parent; that would require searching the file system.

The function is very useful with this restriction, which can be externally worked around if ever necessary, e.g. by tacking the absolute path of the current directory onto both arguments:

  3> (rel-path `@(pwd)/../c` `@(pwd)/a/b`)
  "../kaz/a/b"


That's not really resolving .. though is it? You need both the original path and the output of this function, and one of them always still has .. in it.

Interesting nonetheless; thanks.


It does; for instance:

  2> (rel-path "a/../b/../c/.." "f/../g")
  "g"




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: