search

WebAssembly / wasi-filesystem

Filesystem API for WASI
171 stars 18 forks source link

Support file-dir duality #117

Open SoniEx2 opened 1 year ago

SoniEx2 commented 1 year ago

It would be nice if the filesystem API were allowed to support file-dir duality, tho we wouldn't expect most implementations to support it.

Many filesystems, from Mac "System 7" to Windows NTFS, and beyond, exhibit some form of file-dir duality. Whether the wasi runtime should expose it is another question, and will depend on the wasi runtime's goals, but it would be nice if it were at least allowed.

sunfishcode commented 1 year ago

What is file-dir duality? And how would applications use it?

SoniEx2 commented 1 year ago

sometimes you really want both file and dir contents in the same filesystem node. some systems use these for resource forks. since POSIX doesn't have file-dir duality, and arguably forbids file-dir duality, most POSIX apps use the .d convention. a dir ending in .d is a dir associated with the file lacking the .d. this is most commonly seen in /etc, where you'll have a file like profile and dir like profile.d will hold extra scripts related to profile, or you'll have user.conf and user.conf.d again following roughly the same structure. (these files really wanna be under their parent's namespace, but POSIX doesn't allow it. isn't that unfortunate? we could fix it tho!)

programming languages could use file-dir duality to allow submodules to be loaded from a file-dir node: instead of having, say, foo.rs and foo/bar.rs, you could have foo.rs and foo.rs/bar.rs. the main benefit of this comes when you expose these through a tab-completion interface: file-dir duality allows e.g. f<tab> to always expand to foo.rs, only requiring additional typing for submodules. without file-dir duality, every tab-completion option - except the .d convention, for things that support it - requires multiple <tab>s to complete.