4 ms·

I asked this question just yesterday. The challenge (the one I was interested in) was if this can be done in a general purpose way for arbitrary programming lan

I asked this question just yesterday. The challenge (the one I was interested in) was if this can be done in a general purpose way for arbitrary programming languages so long as they used libc to go through the file system. I actually think it might be theoretically possible using LD_PRELOAD and some equivalent on OSX. I don't know why I'm compelled to want the executable to leave no trace on disk, but it seems much cleaner. However, if you _write_ to the virtual file system, that will need to change the packed binary itself which might result in problems (the binary would grow/shrink as you pack more / less files into it at runtime by writing to the "disk"). https://twitter.com/jordwalke/status/1050277143085608960 https://twitter.com/jordwalke/status/1050277143085608960 Maybe it's just not worth it and a temp directory is not so bad. I just worry about little changes to the way `mktmp` works across OS updates etc. A totally self contained executable that leaves no trace, with virtual file system support is about as isolated and reliable as you could ever hope. I just don't think anyone has been determined enough to achieve it.

marcoperaza 8y ago
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.

marcoperaza 8y ago

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.