That's a reasonable point at an abstract level. But in reality, while you use `open`, `read`, `write` and `close` for files, the equivalent for directories is `opendir`, `readdir`, `closedir`.
I don't see how providing specialized open/read/close calls for directories breaks the file abstraction.
Imagine byte-level access to a directory. You'd have to have some library in userspace that would correctly be able to manipulate that directory's metadata. Now imagine doing that for various filesystems.
Plan 9's namespaces and file-servers were pretty awesome and flexible. It really opened my eyes to the generality of the file abstraction.
I do see how having a specialized set of calls for directories breaks the abstraction that directories are files. Isn't that the very definition of breaking the abstraction?
I mean, as far as I see it, the directory is still a file, of a specific format.
How is that any different than an image file, say, of a particular format? You still need specialized programs in order to manipulate them in a meaningful way. But they're just bytes. Just like the directory is just bytes.
The difference, of course, is that allowing the user to arbitrarily manipulate a directory entry at the byte-level could lead to filesystem corruption.
I'm aware I may be missing something really obvious here. Heck, even contradicting myself :)
Well, you could unify the interface to files and directories by removing all the system calls to deal with opening and closing and reading and writing files, and then removing all the system calls to deal with opening and closing and reading and writing directories, and then simply using ioctl() for everything!
