Re: How to represent the filesystem in DS?

I'd try and track down a copy of The Design and Implementation of the 4.4BSD Operating System ( ISBN 9780768684940 ), specifically Chapter 7: Local Filesystems. While that's (probably) more than you're trying to do, understanding how UFS actually is implemented and the data structures they used can't hurt and should give relevant inspiration.

For instance WRT to your last question of different files with the same name the way I'd approach that would be similar to how most *NIX FSen do it: separate directory entries and naming references from content stored in inodes. You'd have one inode with id XYZ that the name /a/b/c/file1 points to (however), and a different inode of contents DEF that's referenced from the name /x/y/z/file1. If you really wanted to get kind of fancy you could (maybe) use a hash (e.g. sha1 of the contents) as your "inode number" and then you could (for instance) deduplicate things by just creating links to the same underlying storage (instantiated by creating hard links in your real FS when you actually create whatever you're modeling).

Edit: tweaked phrasing about hash. Also another reference for ext2 from Linux.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re: How to represent the filesystem in DS? Select or Download Code

Replies are listed 'Best First'.
Re^2: How to represent the filesystem in DS? by ovedpo15 (Pilgrim) on Mar 27, 2022 at 07:15 UTC
Thank you for the reply! I'm actually familiar with inodes and the way they work (from my OS course back at the uni). Not sure but feels like an overkill (since I just want to keep those paths in a simple structure). Also, is there some model that does something similar maybe? Tried to look in cpan and didn't find anything interesting, but I might missed it.	[reply]
Re^3: How to represent the filesystem in DS? by Fletch (Bishop) on Mar 27, 2022 at 14:46 UTC
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. The cake is a lie. The cake is a lie. The cake is a lie.	[reply] [d/l] [select]


Clear questions and runnable code get the best and fastest answer
	PerlMonks