everything is a directory - Plan9

This is a discussion on everything is a directory - Plan9 ; On Aug 20, 2:01 am, n...@lsub.org (Francisco J Ballesteros) wrote: > Do you prefer embedding the "face" in each mail as metadata instead of > keeping a faces db? That doesn't have anything to do with my point about icons ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 73

Thread: everything is a directory

  1. Re: everything is a directory

    On Aug 20, 2:01 am, n...@lsub.org (Francisco J Ballesteros) wrote:
    > Do you prefer embedding the "face" in each mail as metadata instead of
    > keeping a faces db?


    That doesn't have anything to do with my point about icons for window
    managers, since mail messages are not files, generally speaking. They
    may be stored as files, in which case the mail tool that stores them
    may also include the face as a file attribute -- probably just a uuid
    into the faces db, not the whole image.

  2. Re: [9fans] Re: everything is a directory

    On 8/21/07, jsnx wrote:
    > On Aug 20, 2:01 am, n...@lsub.org (Francisco J Ballesteros) wrote:
    > > Do you prefer embedding the "face" in each mail as metadata instead of
    > > keeping a faces db?

    >
    > That doesn't have anything to do with my point about icons for window
    > managers, since mail messages are not files, generally speaking.


    upasfs(4) In Plan 9 everything is a file (server).

    And that is one more reason why extended attributes make no sense in
    Plan 9, because if you need them it means you have not done a good job
    designing your file server interface.

    uriel

  3. Re: [9fans] Re: everything is a directory

    >> Do you prefer embedding the "face" in each mail as metadata instead of
    >> keeping a faces db?

    >
    > That doesn't have anything to do with my point about icons for window
    > managers, since mail messages are not files, generally speaking. They
    > may be stored as files, in which case the mail tool that stores them
    > may also include the face as a file attribute -- probably just a uuid
    > into the faces db, not the whole image.


    plan9 already supports extended attributes. e.g. upasfs(4) and
    lnfs(4). there are also tools that let you access extended
    attributes created on other systems: aux/olefs

    maybe you should ask the "right" fs:

    % upas/fs
    % grep jason /mail/fs/mbox/*/from

    or

    % lnfs /
    % touch /usr/glenda/other_examples_of_file_as_a_filesystem_include_MS_ OLE_structured_storage


  4. Re: everything is a directory

    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.

  5. Re: everything is a directory

    "jsnx" wrote in message
    news:1187630509.315942.311670@m37g2000prh.googlegr oups.com...
    > Putting attributes in the same namespace as files introduces a whole
    > new problem -- just as storing ownership in foo/.owners would.


    I don't see why. Attributes have to be attached to a specific file,
    so why not attach them "in the usual way" rather than inventing a
    new mechanism? If .owners was enforced by the OS then why
    couldn't it be attached in the usual namespace?

  6. Re: [9fans] Re: everything is a directory

    Do the arguments for extended attributes stem from a desire to store
    info for backups/HSM and for version control systems?

    Icons are the responsibility of the desktop manager.

    Faces are stored in their own "database" on plan9.

    We don't have resource forks - the window managers (rio and acme)
    keep all the widgets need to display any plan9 program internally (some
    colours, textures, cursors, menuhit tables).

    Perhaps the reason plan9 doesn't see the need for extended attributes
    is the same as the reason it doesn't need backup systems, HSM, and
    version control software - has fossil and venti (or kenfs depending on
    your taste) solved this problem for us?

    Maybe there are other examples of where extended attributes are really
    useful?

    I'am not trolling, I just don't see their efficacy in plan9.

    -Steve

  7. Re: everything is a directory

    jsnx wrote:
    > Now, here is the tough part, I think -- say I want to use version
    > control with the above example. ...
    > That seems pretty unworkable to me, ...


    The problem seems to me to be in the design of that version control
    system.

    You might work around it by keeping the version archives in one place
    and the working copies you actually use in another place.

  8. Re: everything is a directory

    On Aug 23, 1:50 am, "Douglas A. Gwyn" wrote:
    > If .owners was enforced by the OS then why
    > couldn't it be attached in the usual namespace?


    Well, that could lead to a lot of 'reserved words' in the filesystem.
    Down that road lay the IANA...

  9. Re: everything is a directory

    On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    > I'am not trolling, I just don't see their efficacy in plan9.


    I don't see how to architect the system I discussed without attributes.

  10. Re: [9fans] Re: everything is a directory

    * jsnx (jason.dusek@gmail.com) wrote:
    > I don't see how to architect the system I discussed without attributes.


    It's not hard to conceive a system that requires _any- set of features. Not
    impressed.


  11. Re: [9fans] Re: everything is a directory

    On 8/24/07, jsnx wrote:
    >
    > On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    > > I'am not trolling, I just don't see their efficacy in plan9.

    >
    > I don't see how to architect the system I discussed without attributes.
    >


    I can...

    Build yourself a file server that provides the environment you want with
    attributes... don't inject it into the core system. Store it for real in
    fossil files with a certain format.

    Done?

    Plan 9's ability to have synthetic filesystems seems to do away with the
    need to change the way the core filesystems work.

    If you need the filesystem to behave or to have different semantics it can
    clearly be done. Seen the TCP interface for instance? sshnet? Sure
    sometimes we have to make small compromises in the way the system works to
    achieve some new functionality, but when we do, we seem to be buying a lot
    for our trade up. (my understanding is sshnet did require some changes to
    the way the system worked before sshnet was proposed.)

    Plan 9 seems to have always been about trying to solve problems in a way
    that's simpler than the way things seem to have turned out in Linux/Unix
    etc.


  12. Re: everything is a directory

    On Aug 24, 3:55 am, leim...@gmail.com (David Leimbach) wrote:
    > On 8/24/07, jsnx wrote:
    > > On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    > > > I'am not trolling, I just don't see their efficacy in plan9.

    > > I don't see how to architect the system I discussed without attributes.

    > Build yourself a file server that provides the environment you want with
    > attributes... don't inject it into the core system. Store it for real in
    > fossil files with a certain format.
    >
    > Done?


    If I want to have a system with the features of two distinct
    filesystems, what then? Attributes allow for composition, whereas the
    FS oriented approach appears not to.

    I would have to write (or obtain) a TeX fs, a SVN fs and then a TeX-
    SVN fs if I wanted to have those feature sets independently, if I am
    understanding you correctly.

  13. Re: everything is a directory

    On Aug 24, 1:58 am, m...@gmx.net (Martin Neubauer) wrote:
    > * jsnx (jason.du...@gmail.com) wrote:
    > > I don't see how to architect the system I discussed without attributes.

    >
    > It's not hard to conceive a system that requires _any- set of features. Not
    > impressed.


    Martin, your posts on this thread have been just awesome so far. Keep
    up the good work!

  14. Re: everything is a directory

    "jsnx" wrote in message
    news:1187900988.333897.37270@e9g2000prf.googlegrou ps.com...
    > On Aug 23, 1:50 am, "Douglas A. Gwyn" wrote:
    >> If .owners was enforced by the OS then why
    >> couldn't it be attached in the usual namespace?

    > Well, that could lead to a lot of 'reserved words' in the filesystem.


    Probably it should be .attributes/owner, no new added word beyond
    what would be needed for extended attributes anyway.

  15. Re: [9fans] Re: everything is a directory

    Fossil already provides something like 'svnfs' (but much simpler and
    saner), as far as I can see your proposed texfs is no different
    conceptually from upasfs, and nothing keeps you from using both
    together.

    And I certainly fail to see how adding attributes into the mix makes
    composition any easier, they just add another meta-namespace with its
    own ambiguities and clashes.

    In the end, it is also good to remember that file servers, while
    incredibly powerful, are not the perfect abstraction for everything,
    when it comes to composition the tool/text-strem original unix
    philosophy (this days lost everywhere except in Plan 9) is still the
    most powerful, file servers simply and transparently expand the
    environment where tools live and interact.

    Not everything needs to be a file server, but everything should handle
    text streams (ie., pipes or files).

    Best wishes

    uriel

    On 8/29/07, jsnx wrote:
    > On Aug 24, 3:55 am, leim...@gmail.com (David Leimbach) wrote:
    > > On 8/24/07, jsnx wrote:
    > > > On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote:
    > > > > I'am not trolling, I just don't see their efficacy in plan9.
    > > > I don't see how to architect the system I discussed without attributes.

    > > Build yourself a file server that provides the environment you want with
    > > attributes... don't inject it into the core system. Store it for real in
    > > fossil files with a certain format.
    > >
    > > Done?

    >
    > If I want to have a system with the features of two distinct
    > filesystems, what then? Attributes allow for composition, whereas the
    > FS oriented approach appears not to.
    >
    > I would have to write (or obtain) a TeX fs, a SVN fs and then a TeX-
    > SVN fs if I wanted to have those feature sets independently, if I am
    > understanding you correctly.
    >


  16. Re: everything is a directory

    On Aug 29, 2:06 am, "Douglas A. Gwyn" wrote:
    > "jsnx" wrote in message
    > > On Aug 23, 1:50 am, "Douglas A. Gwyn" wrote:
    > >> If .owners was enforced by the OS...

    > > ...that could lead to a lot of 'reserved words'...

    >
    > Probably it should be .attributes/owner, no new added word beyond
    > what would be needed for extended attributes anyway.


    That's a good idea, and I think that brings us full circle. If we
    allow for a
    ..attributes/content which is accepted by all the major tools, then
    what I want
    to do is done.

  17. Re: [9fans] Re: everything is a directory

    On 8/30/07, jsnx wrote:
    >
    > On Aug 29, 2:06 am, "Douglas A. Gwyn" wrote:
    > > "jsnx" wrote in message
    > > > On Aug 23, 1:50 am, "Douglas A. Gwyn" wrote:
    > > >> If .owners was enforced by the OS...
    > > > ...that could lead to a lot of 'reserved words'...

    > >
    > > Probably it should be .attributes/owner, no new added word beyond
    > > what would be needed for extended attributes anyway.

    >
    > That's a good idea, and I think that brings us full circle. If we
    > allow for a
    > .attributes/content which is accepted by all the major tools, then
    > what I want
    > to do is done.
    >


    I'm a bit confused at this point... What is this proposal and why is it
    attractive?

    On the surface it looks like you could get everything you want using a pair
    of files to me. One to tell you the start of the file's normal data (or the
    end), and the other to let you have scratch space for arbitrary key/value
    pairs.

    The secondary file is just then a table of contents for the original file
    that just happens to hold both the core file data and the other gunk that
    goes with it.... which brings me back to the idea that these problems should
    have been solved in the file formats themselves (and again, not terribly
    sure that ACLs or such could have been safely implemented in that way, my
    understanding is that is how the extended attributes can be put to good use
    on other filesystems)


    Dave


  18. Re: [9fans] Re: everything is a directory

    On 8/30/07, jsnx wrote:

    > On Aug 29, 2:06 am, "Douglas A. Gwyn" wrote:
    > > "jsnx" wrote in message
    > > > On Aug 23, 1:50 am, "Douglas A. Gwyn" wrote:
    > > >> If .owners was enforced by the OS...
    > > > ...that could lead to a lot of 'reserved words'...

    > >
    > > Probably it should be .attributes/owner, no new added word beyond
    > > what would be needed for extended attributes anyway.


    > That's a good idea, and I think that brings us full circle. If we allow for a
    > .attributes/content which is accepted by all the major tools, then what I want
    > to do is done.


    > I'm a bit confused at this point... What is this proposal and why is it attractive?


    > On the surface it looks like you could get everything you want using a pair of files to me. One to tell you the start of
    > the file's normal data (or the end), and the other to let you have scratch space for arbitrary key/value pairs.


    > ...


    The proposal, as modified, provides a mechanism that can be used to
    add extended attributes to files, to encode existing attributes for
    files, and to associate all kinds of other files with given files.

    The attribute names (analogous to Linux/Solaris extended attributes)
    would all be filenames within the .attributes directory attached to
    the target file, and their values would be the contents of those
    named files.

    My proposed implementation, for any Unix-like system including
    Plan9, is to change read() on a directory to instead read from the
    directoryname/.data file, if it exists, or report an error if it
    doesn't exist. This change should cause no disruption to existing
    file structures or applications, since as it stands there is no
    purpose in read()ing the contents of a directory (these days we use
    walk(), getdents(), etc. instead). Almost all utilities, including
    "tar", would continue to do "the right thing". Probably "cp" would
    need to be changed so it copies directory trees as well as ordinary
    files. Note that there would still be "leaf" (non-directory) files
    under my proposal, particularly .data files and not-yet-converted
    existing ordinary files. If one wanted to totally convert the
    storage filesystem, then .data entries could be hidden and then all
    visible files would indeed be directories.

    The primary purpose is to provide support for extended attributes
    in a way that works within the traditional Unix hierarchical file
    model, without requiring extensive kludges like the Linux/Solaris
    implementations have. A two-file model would also require a large
    amount of ad-hoc kludgery to work well enough.

  19. Re: [9fans] Re: everything is a directory

    On 8/31/07, Douglas A. Gwyn wrote:
    > My proposed implementation, for any Unix-like system including
    > Plan9, is to change read() on a directory to instead read from the
    > directoryname/.data file, if it exists, or report an error if it
    > doesn't exist. This change should cause no disruption to existing
    > file structures or applications, since as it stands there is no
    > purpose in read()ing the contents of a directory (these days we use
    > walk(), getdents(), etc. instead).


    See /sys/src/libc/9sys/dirread.c and read(5). Plan 9 doesn't have a
    distinct system call for reading directory entries.

    --Joel

  20. Re: [9fans] Re: everything is a directory

    With this way of thinking we will never catch up with lunix's 400
    syscalls (and counting, not to mention the ioctls)!

    uriel

    > See /sys/src/libc/9sys/dirread.c and read(5). Plan 9 doesn't have a
    > distinct system call for reading directory entries.
    >
    > --Joel
    >


+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast