Hacker News Reader

Comment by tetris11 | Hacker News Reader

So if i'm getting this, they initialise find in some kind of infinite looping state using its own parameters to create and nest directories, and define a halting state from whether it reaches the max number of nested directories where find quits.

I didnt understand the encoding part

View on HN

Only read the abstract, but if as I suspect it is using nested directories as "cells" in the "tape", the proof will require directories to be able to nest arbitrarily deep (which maybe some filesystems already permit; but even if all existing filesystems have some finite limit, this would not be considered an obstacle to the result, since it's certainly possible to construct a filesystem where directory nesting level is limited only by storage size). That's because it needs to be able to simulate a Turing Machine, which could read and write an infinite amount of storage.

Then, there just needs to be a way to force find to stop in some finite amount of time -- that's the halting state. I don't know what mechanism they use for that, but if I were trying to do this, I would lean towards looking for a way to make it error out.

I don’t think most modern file systems have any limit to the depth of nested directories, that’s not how directory trees work. There are other limits like the number of objects in the file system. The ability to reference an arbitrary path is is defined by PATH_MAX, which is the maximum string length. You can still access paths longer than string length, just not in a single string representation.

Isn't there a max filepath length? Or does find not ever deal with that and just deal in terms of building its own stack of inodes or something like that?

That’s what PATH_MAX is. It’s the size of the buffer used for paths - commonly 4096 bytes. You can’t navigate directly to a path longer than that, but you can navigate to relative paths beyond that (4096 bytes at a time).

Reply on news.ycombinator.com