On Fri, Nov 14, 2008 at 12:52 AM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote:
> On Nov 13, 2008, at 8:37 AM, Dan Cross wrote:
>>
>> [...]
>
> But along the very same line of thought -- wouldn't it also then be
> much more reasonable to stick with an "alternative aname"
> approach when adopting 9P for symlinks, FIFOs and the
> rest of the POSIX paraphernalia?
>
> You pay with a slightly more complicated server, but you
> reap a huge benefit in a form of:
>
> term% srvssh unix unix-fs
> term% mount /srv/unix-fs /n/unix-fs
> term% mount /srv/unix-fs /n/unix-fs-symlinks posix-symlinks
> # Look ma, I'm creating a symbolic link from a Plan9 terminal
> # I'll name it after you and it'll point to the root
> term% echo / > /n/unix-fs-symlinks/home/glenda/mama
> # And I can even do readlink()
> term% cat /n/unix-fs-symlinks/home/glenda/mama
> /
> # Best of all -- it all works as expected
> term% cd /n/unix-fs/home/glenda/mama
> term% ls
> bin cdrom etc initrd initrd.img.old lib32 lost+found mnt
> proc sbin sys usr vmlinuz
> boot dev home initrd.img lib lib64 media opt
> root srv tmp var vmlinuz.old
There's certainly an esthetic niceness to that for symlinks and the
rest of the weird POSIX gunk; I don't know how well it might work for
something like locks, but maybe I'm just blinded by too many years
drinking at the Unixbar and not seeing beyond my own conceptual
roadblocks. It does strike me that a similar approach may be more
elegant for getting weird types of metadata in and out of some funky
filesystem than overloading a directory type in stat and wstat (which
itself could be a slippery slope). I guess the two considerations
there are overall system consistency and how much one wants to try and
make something weird "fit in" with the rest of the system.
- Dan C.
