Hi - I am looking to build a fuse-based file system that implements a version of
variant symlinks using
go-fuse. 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,
GOPATH 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,
rbenv 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.
Thanks