From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Date: Thu, 23 Aug 2007 08:49:48 +0000
From: jsnx <jason.dusek@gmail.com>
Message-ID: <1187807457.316205.221560@q3g2000prf.googlegroups.com>
Content-Type: text/plain; charset="us-ascii"
References: <1187631614.5062.772.camel@work.sfbay.sun.com>
Subject: [9fans] Re: everything is a directory
Topicbox-Message-UUID: b037a04c-ead2-11e9-9d60-3106f5b1d025

On Aug 20, 10:53 am, urie...@gmail.com (Uriel) wrote:
> Sad thing is that when you try to convince Unix people of the power of
> private namespaces, they complain that they seem 'too confusing'...
> yea, because symlinks, extended attributes and other such hideous
> hacks are so much nicer...

Let's return to my original post and one of the use cases I mentioned
there. Say I have TeX document with innumerable sections in it,
sections that I would like to handle 'file style', for good
interaction with version control. I do not want a lot of include
directives and other crap, though -- I don't want to actually make the
new files. Let us imagine a TeX filesystem:

  sec/
    matter
    images
    sec0/
      matter
    sec1/
    ...and so on...

This filesystem has two forms -- serialized form and hierarchical
form. In serialized form, it is a TeX file; I mount this file to get
the example above.

Now, here is the tough part, I think -- say I want to use version
control with the above example. I check the directories into my
version control system, which pollutes the TeX fs with a bunch of .svn
directories. This makes my filesystem puke; so I rewrite it to ignore
the .svn thingies. Very good; but, I'm still not finished. Because I
checked the dirs, and not their serialized master, into version
control, I have big problem when I check the thing back out -- it is
now a normal filesystem, full of files and dirs, that has forgotten
it's TeX nature. I have to do a cast -- Iinstantiate it as a normal fs
and then cast it to a TeX fs.

That seems pretty unworkable to me, but I'm very new to Plan 9 and
there's probably something here I'm missing. With attributes and my
dir/file system, there is only one way to mount something, so I am in
no danger of losing my metadata when I try to compose filesystems (in
this case, I am composing an ad-hoc 'version controlled filesystem'
with a TeX filesytem). I can use more than one kind of metadata at a
time. However, in the metadata-in-fs approach, a resource can only be
governed by metadata from one or another filesystem at any given time;
a real problem for the application I am considering.