[terlisimo]

> you’ll never count to “orange” - “orange”

Ok but I don't see how that relates to the idea of storing sequences of numbers (the basic function of a filesystem) in Pi. Orange is not a number so it doesn't make sense to look for it in any sequence of numbers. "Orange" can however be represented as a sequence of ASCII characters, and if every sequence of numbers is contained in Pi, then an ascii representation of any string can also be found.

> This will get large very quickly.

Right, but here's a thought...

Suppose the place in Pi where your sequence is located is huge. You could maybe (probably) find a sequence earlier in Pi that is a pointer to your actual location :) So the metadata would need like 3 things to make this work. 1) length of your data, 2) checksum of your data and 3) pointer into Pi. If hash of (pointer+length) doesn't match checksum, it's a pointer (which may point to a different pointer etc).

That might make it compress a bit better. Although you may need huge amount of RAM just to dereference the pointers.

[r3trohack3r]

> Suppose the place in Pi where your sequence is located is huge. You could maybe (probably) find a sequence earlier in Pi that is a pointer to your actual location

If the sequence of bytes necessary to represent the file encodes to an integer index into pi, and that integer index encodes to a sequence of bytes larger than the original file, I have no reason to believe trying to repeat that process would result in anything other than an even larger integer index.