> So I am glad to post here the announcement for the first version of
> symlinkfs.
[snip]
> Symlinkfs is a filesystem for Linux. A symlinkfs filesystem is composed
> by only one directory which contains several symbolic links.
>
> The name of the links and the their destination are calculated each time
> a user enters this directory (or accesses a file from the directory).
>
> The names and the destinations are based on fixed strings or on users'
> environment variables. Users who have different values for the
> environment variables see different files in the directory.
(BTW have you read the recent linux-kernel thread about "varlinks"? They
seem to be to be very similarly inspired. Either you are working with the
people who want varlinks, or somebody is doing redundant work ;)
I have one minor suggestion -- change the name.
Several people have objections, I think, to something that changes the
semantics of the symlink call... I would submit that the same could be said
about something called "symlinkfs" which isn't (just) a filesystem of
symlinks. Perhaps "varfs" or "symfs" or "linkfs" or "envfs"... just please
keep from calling it "symlink" something, because it's not!
It seems to me this topic has come up before, at least once -- making an
"envlink" whose path resolves differently depending on environment variables,
etc. IIRC it drew a lot of security concerns (as a proposed extention to
ext2), as various issues were still kind of "muddy". Not to say these issues
can't be worked out to everybody's -- well, *most* people's -- satisfaction,
they just weren't, yet. I've just searched through my archives, though, and
couldn't find any such threads...
I am reminded of the transname patch, though. That was a pretty neat trick,
but it looks like it's been dead for a while. [ Transname allowed NFS
clients to see different real files based on their hostname, i.e. client1
requesting /etc/inittab --> /etc/inittab:client1. Nice for diskless,
NFS-rooted boxes. ] You might want to communicate with Greg Alexander
<gralexan@indiana.edu>, who has said he (may) revive it for the 2.1.9x/2.2
kernels. The specifics are quite different, but I wonder if the
implementations might share a good amount of logic.
Hank Leininger <hlein@progressive-comp.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu