Hacker News Reader

Comment by akerl_ | Hacker News Reader

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 “..”: they’ve implemented a path sanitization library, similarly to how many other frameworks (notably those designed to serve files over the web) behave.

View on HN

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.

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.)

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.

Reply on news.ycombinator.com