That’s a good idea, doing it by shimming libc, but it feels kind of fragile. Go, for example, does not use libc and makes syscalls directly instead, so this wou

That’s a good idea, doing it by shimming libc, but it feels kind of fragile. Go, for example, does not use libc and makes syscalls directly instead, so this would not work for any fs-accessing Go code either in the application or its dependencies. Even for things that do go through libc, wouldn’t you end up in a cat and mouse game to add shims for any new file operations added to the kernel? I suspect even shimming the existing interfaces is less straightforward than at first thought. I don’t think you can have a truly robust solution without kernel support. Maybe the FUSE kernel-side code already supports, or could be modified to support, per-process ad-hoc virtual file systems? If done right, you might even get existing fs caching and other optimizations for (closed to) “free”. I also can’t quite explain why I find this so desirable. It just feels intuitively cleaner and more robust to not have to spray files elsewhere into some cache.