3 ms·

Given that they’re still resolving “..”, they’re just resolving it in code client-side before requesting the content, they really haven’t gotten rid of “..”: th

• ivanbakel 8y ago
  That is getting rid of ".." - the client-side version is fundamentally different in behaviour, since it can't be resolved without prior knowledge of the filesystem. ".." isn't being sanitised from user paths, it's being translated, because there is no equivalent concept in the file server.
• itp 8y ago
  No, it's deeper than that. They are describing the capabilities of a process handed a file descriptor, which means it does not have a path at all. There's no way to resolve '..' relative to no path. Compare that to a POSIX system where a directory has an actual child which is a reference to the directory's parent whose name is always '..'. The talk about resolving '..' is merely a demonstration that the behavior of "cd .." can be supported/emulated in a context where you have both an open directory and corresponding path, without requiring that '..' literally exist.
  • loeg 8y ago
    To add to that, as the document writes in the very first section, it can sort of be thought of as a chroot. You can't .. out of a chroot; there is no "..". (Yeah, it's not exactly a chroot; that's well covered in the document.)