Date: Thu, 13 Feb 2014 23:37:49 -0600 From: Jim Thompson <jim@netgate.com> To: Jordan Hubbard <jordan.hubbard@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Thoughts on Multi-Symlink Concept Message-ID: <40637D5C-EBBB-49C0-BE82-BA644C32D778@netgate.com> In-Reply-To: <EEC374CA-8B26-4AAA-ADCF-186EE69AB228@gmail.com> References: <CAO2cuEMC==HstC4VkkiFpHyo6LA_xyCjYKvCEECXneVLNnZpZg@mail.gmail.com> <A31B3F88-861F-459B-AD67-F146D5514594@mail.turbofuzz.com> <EEC374CA-8B26-4AAA-ADCF-186EE69AB228@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 12, 2014, at 11:17 PM, Jordan Hubbard <jordan.hubbard@gmail.com> = wrote: >=20 > On Feb 12, 2014, at 9:08 PM, Jordan Hubbard <jordan.hubbard@gmail.com> = wrote: >=20 >> Globbing is done in user land (by the shell) - you wouldn=92t want to = push that down into the kernel, which is either what you=92d have to do = or you=92d 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 =93symlink=94. >=20 > 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=92d just be stacking one weird hack = on top of another weird hack. It=92s still not a good idea for all the = reasons I mentioned, at least not as a =93symlink=94. Maybe some new = type of shell builtin, though I=92m not sure how/where you=92d use it. There is a fourth way. Just embed a (call to a) shell script in the = symlink. If Pyramid=92s conditional symbolic links were the computed = goto of the filesystem, and variant symlinks are a modern .. er=85 = variant of same, =20 then embedding a call to an external program has to be the = Turing-complete =85 er=85 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. =95 libc asks the root filesystem server about /mnt/readme.txt. =95 The root filesystem returns a port to the mnt filesystem = server (matching /mnt) and the retry name /readme.txt. =95 libc asks the mnt filesystem server about /readme.txt. =95 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=85. 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40637D5C-EBBB-49C0-BE82-BA644C32D778>