12 ms·

Reading that post indicates that he regrets the existence of hidden files, not the existence of '.' and '..'

by ori_b 8y ago

tyingq 8y ago
Yes, that's right. He does have issues with how ".." works in Unix though. There's a pretty detailed explanation from him here: http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames (scroll down to about the third appearance of "..")
cyphar 8y ago
Yes, though Plan9's implementation of ".." Is incredibly different to Unix. It's treated as a lexical token rather than an actual directory entry, and so therefore certain strange cases with symlinks are handled differently (though Plan9 doesn't have symlinks either). From memory Rob Pike had a blog post about this problem and why Plan9 does lexical path cleaning on all paths before resolution.
- IgorPartola 8y ago
  I had no idea .. wasn’t treated as a lexical token in POSIX. Why the hell is it not and what would break if it suddenly was? Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary?
  - cyphar 8y ago
    The most obvious example of something that would break is any code that uses symlinks. Here's an example: % ln -s foo/bar/baz link % ls ./link/.. This resolves in POSIX to "./foo/bar", not "." (which is how it would resolve in Plan9 if Plan9 had symlinks). If you treated ".." as a lexical token you'd have to sanitise it before doing anything else and thus you'd end up with Plan9-like semantics. You could also make the argument that Plan9's ".." semantics actually cause inconsistencies between "cd $path; ls .." and "ls $path/.." -- and this is especially true for Linux's "magic links" in procfs. So if you prefer a consistent VFS then making ".." a lexical token is not the best idea. > Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary? I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall.
    - IgorPartola 8y ago
      I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no? > I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall. From http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames > A new kernel call, fd2path, returns the file name associated with an open file, permitting the use of reliable names to improve system services ranging from pwd to debugging. Although this work was done in Plan 9, Unix systems could also benefit from the addition of a method to recover the accurate name of an open file or the current directory.
      - cyphar 8y ago
        > I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no? You could, but that doesn't really change the point of my comment -- "." is very trivial to handle either lexically or as a directory entry and generally Linux's handling of it is basically a no-op (though it should be noted that it's a no-op compared to $path/ not $path -- which is an important distinction with symlinks-to-directories or mountpoints). The key difference is whether the symlink is actually resolved (and thus ".." applies to the partially-resolved prefix of the path resolution) or if it applies to the symlink component itself (and thus it never gets resolved). > A new kernel call, fd2path, returns the file name associated with an open file [...] fd2path goes from fd -> path, which is the inverse operation to path resolution. All path resolution in Plan9 goes through cleanpath() (as far as I know). fd2path is similar to readlink(/proc/$pid/fd/$fd) on Linux. The two things are separate concepts.
        IgorPartola 8y ago
        I am starting to see why symlinks screw everything up. I guess I come at it from the URI standpoint: `https://example.com/foo/../bar/` https://example.com/foo/../bar/` should be resolvable client-side to `https://example.com/bar/` https://example.com/bar/` without having to worry about what's on the server, right? So I'd say the path should be processed the same way: without looking at the filesystem first. I'd advocate that the `/../` should be applied before the symlink is resolved because when I am in `/home/me/bar/` and I say `cd ..` I mean "go to `/home/me`" not to some arbitrary part of the filesystem.

Reading that post indicates that he regrets the existence of hidden files, not the existence of '.' and '..'

by ori_b 8y ago

Reading that post indicates that he regrets the existence of hidden files, not the existence of '.' and '..'

Yes, that's right. He does have issues with how ".." works in Unix though. There's a pretty detailed explanation from him here: http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames (scroll down to about the third appearance of "..")

cyphar 8y ago

Yes, though Plan9's implementation of ".." Is incredibly different to Unix. It's treated as a lexical token rather than an actual directory entry, and so therefore certain strange cases with symlinks are handled differently (though Plan9 doesn't have symlinks either). From memory Rob Pike had a blog post about this problem and why Plan9 does lexical path cleaning on all paths before resolution.

IgorPartola 8y ago
I had no idea .. wasn’t treated as a lexical token in POSIX. Why the hell is it not and what would break if it suddenly was? Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary?
- cyphar 8y ago
  The most obvious example of something that would break is any code that uses symlinks. Here's an example: % ln -s foo/bar/baz link % ls ./link/.. This resolves in POSIX to "./foo/bar", not "." (which is how it would resolve in Plan9 if Plan9 had symlinks). If you treated ".." as a lexical token you'd have to sanitise it before doing anything else and thus you'd end up with Plan9-like semantics. You could also make the argument that Plan9's ".." semantics actually cause inconsistencies between "cd $path; ls .." and "ls $path/.." -- and this is especially true for Linux's "magic links" in procfs. So if you prefer a consistent VFS then making ".." a lexical token is not the best idea. > Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary? I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall.
  - IgorPartola 8y ago
    I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no? > I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall. From http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames > A new kernel call, fd2path, returns the file name associated with an open file, permitting the use of reliable names to improve system services ranging from pwd to debugging. Although this work was done in Plan 9, Unix systems could also benefit from the addition of a method to recover the accurate name of an open file or the current directory.
    - cyphar 8y ago
      > I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no? You could, but that doesn't really change the point of my comment -- "." is very trivial to handle either lexically or as a directory entry and generally Linux's handling of it is basically a no-op (though it should be noted that it's a no-op compared to $path/ not $path -- which is an important distinction with symlinks-to-directories or mountpoints). The key difference is whether the symlink is actually resolved (and thus ".." applies to the partially-resolved prefix of the path resolution) or if it applies to the symlink component itself (and thus it never gets resolved). > A new kernel call, fd2path, returns the file name associated with an open file [...] fd2path goes from fd -> path, which is the inverse operation to path resolution. All path resolution in Plan9 goes through cleanpath() (as far as I know). fd2path is similar to readlink(/proc/$pid/fd/$fd) on Linux. The two things are separate concepts.
      - IgorPartola 8y ago
        I am starting to see why symlinks screw everything up. I guess I come at it from the URI standpoint: `https://example.com/foo/../bar/` https://example.com/foo/../bar/` should be resolvable client-side to `https://example.com/bar/` https://example.com/bar/` without having to worry about what's on the server, right? So I'd say the path should be processed the same way: without looking at the filesystem first. I'd advocate that the `/../` should be applied before the symlink is resolved because when I am in `/home/me/bar/` and I say `cd ..` I mean "go to `/home/me`" not to some arbitrary part of the filesystem.