2 ms·

> 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,

by 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.
- cyphar 8y ago
  Actually, in the case of "cd .." shells will often try to fake how symlink resolution actually happens. You can see this if you "cd" into a symlink, you shell's $PWD and built-in pwd command will tell you that you're inside the symlink but not the actual directory you got thrown into. This results in "cd .." actually doing what you describe -- even though it's a complete fantasy invented by your shell. Try it out.

by cyphar 8y ago

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.

cyphar 8y ago
Actually, in the case of "cd .." shells will often try to fake how symlink resolution actually happens. You can see this if you "cd" into a symlink, you shell's $PWD and built-in pwd command will tell you that you're inside the symlink but not the actual directory you got thrown into. This results in "cd .." actually doing what you describe -- even though it's a complete fantasy invented by your shell. Try it out.