Thoughts on Multi-Symlink Concept

[Jim Thompson]

On Feb 12, 2014, at 11:17 PM, Jordan Hubbard <jordan.hubbard at gmail.com> wrote:

> 
> On Feb 12, 2014, at 9:08 PM, Jordan Hubbard <jordan.hubbard at gmail.com> wrote:
> 
>> Globbing is done in user land (by the shell) - you wouldn’t want to push that down into the kernel, which is either what you’d have to do or you’d need a user land daemon which did round-trips with the kernel to do the translation, which would also need to make sure to get all of the process permission stuff right since the user id / gid / $CWD would all potentially affect the expansion of the “symlink”.
> 
> Actually, just to correct myself, there is a third way, which is that you could make the shell also do the expansion of the symlink (or interpose it into libc), but now you’d just be stacking one weird hack on top of another weird hack.  It’s still not a good idea for all the reasons I mentioned, at least not as a “symlink”.  Maybe some new type of shell builtin, though I’m not sure how/where you’d use it.

There is a fourth way.  Just embed a (call to a) shell script in the symlink.   If Pyramid’s conditional symbolic links were the computed goto of the filesystem, and variant symlinks are a modern .. er… variant of same,  
 then embedding a call to an external program has to be the Turing-complete … er… variant.  amiright?

What could go wrong?  :-)

OK, seriously..  once upon a time there was an OS named Mach.  It had the concept of a name server.

Pathname resolution worked like this:

consider /mnt/readme.txt where /mnt is a mounted filesystem.

	• libc asks the root filesystem server about /mnt/readme.txt.
	• The root filesystem returns a port to the mnt filesystem server (matching /mnt) and the retry name /readme.txt.
	• libc asks the mnt filesystem server about /readme.txt.
	• The mnt filesystem server returns a port to itself and records that this port refers to the regular file /readme.txt.

While a regular filesystem server will just serve the data as stored in a filesystem on disk, on Mach there can be servers providing purely virtual information, or a mixture of both.
In Mach-land, it is up to the server to behave and provide consistent and useful data on each remote procedure call. If it does not, the results may not match the expectations of the user and confuse him.

You are lost in a maze of twisty little filesystems, all alike….

OK, more seriously.

This seems straight-forward to implement via FUSE.  You might look at fsfipl & filterFS
http://sourceforge.net/projects/fsfipi/
http://filterfs.sourceforge.net.