Now when I'm saying "inode" that's probably a bad name for it because no you don't really need to do a full "inode" with indirect/double indirect pointers to storage blocks and what not (you can just cheat and use your actual underlying filesystem for storage and keep just a path to the contents instead which you read into the destination as required when you actually need to realize things).

As for existing modules, there might be some helper stuff in something meant to be used with Fuse to implement a filesystem but that's a pure guess. As you've seen Graph isn't quite going to do it because you'd (maybe; warning ENOCAFFEINE and this is off the cuff) want to store attributes (the name a target node is to be referenced as) on the edges. Something like REST::Neo4p leveraging a graph database would get you closer to that model but I think that'd would be even worse overkill.

I'd just start simple with a Directory instance which has many DirectoryEntries, which have a name and point to a target. A target would be maybe either a FileContents instance containing, erm, the contents (or a pointer to a real file with) or a SymbolicLink being the name of the target. Once you've got those work from there. Edit: Derp, just saw your edit to the original which is along similar lines; so yeah that's reasonable.