Hi - I am looking to build a fuse-based file system that implements a version of variant symlinks
. Some very rough initial code on Github:
The idea being that with time this will accept mount requests of the form:
var-sym-fs <ROOT_DIR> <ENV_VAR_NAME> <MOUNT_POINT>
So for example:
var-sym-fs /home/myitcv/.gos GO_VERSION /home/myitcv/go
with the command:
GO_VERSION=go1.2.1 ls /home/myitcv/go
would list the contents of /home/myitcv/.gos/go1.2.1.
Furthermore (and this is potentially the more powerful use case), PATH
etc could be defined to include paths that are themselves variant symlinks. This would take away a lot of the pain for version managers, gvm
and the like (slight caveat here because there are some important use cases var-sym-fs
would not handle where gvm pkgset
does, for example local pkgset's)
Ignoring the expense of such a file system (for now at least), I've hit upon an issue that I think relates to this discussion on the LKML
My fuse-based file system works by examining the environment of the calling process in order to resolve the variant symlink. If however that process is performing an execve
with a filename argument that corresponds to a file within my fuse file system, I essentially hit deadlock because I can't perform an open
on the /proc/PID/environ of the calling process.
The LKML discussion suggests the locking of /proc/PID/environ during an execve is intentional. But my knowledge/understanding of the Linux kernel code is not good enough to verify my anecdotal findings.
Can anyone suggest an alternative approach that might allow this to work? (realising this is not strictly speaking a Go question)
Any feedback greatly appreciated. The code is intentionally very rough right now... until such time as I make headway with the execve issue.