lkml.org 
[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NTFS-like streams?

    For what it's worth, my list of semantics for EAs/forks (NOT structured
    storage. *please* note the difference):

    - EAs can vanish. Anything using them must expect this to happen.

    - EAs are not heirachical - a file can have EAs associated with it, but an
    EA cannot have more EAs associated with that.

    - Files with associated EAs look like files. stat() should return a
    S_COMPLEX, or something, but to the user, a file is still a file.

    - Being able to access EAs using a specific naming techinque (such as
    file/EA-name, or file:EA-name) would be useful (and probably the most
    sensible way of going about things)

    - A file+EAs is not a directory. Ideally, opendir(file) would fail, as it
    does now (and an additional call to open the file for enumerating the
    EAs should be added, although there's no reason why it couldn't return
    a DIR * instead of some redudant new type)

    - EAs can be useful, even where the OS wasn't built from the ground up to
    support them (because of their 'optional' nature).

    - Access permissions of EAs could either inherit totally from the file
    associated with them. Alternatively, one could specify an alternative
    (slightly more complex) way of doing it:

    * You cannot write to an EA unless you can write to the associated file.
    * You can read an EA if you can read the directory containing the file.
    (So you can get the icon for a file, even if you can't actually get
    the file itself - neater from a user perspective).
    * You cannot remove/rename an EA unless you can write to the associated
    file.
    * You cannot list EAs unless you can read the file (not sure about the
    point of this one, but it seems logical).

    Everyone else can decide on whether EAs could ever be
    executable. Although I could see the merit of attaching a special
    wrapper shell-script around a program, and storing it as an EA
    associated with the program's executable, I'm not sure it wouldn't just
    complicate matters horribly (and confuse users).

    On the other hand, for structured storage:

    - A file is a directory is a file. The difference is the attribute and how
    that makes things appear to the user. The whole thing is heirachical,
    though (i.e., sub-files have the same semantics as files).

    - Nothing's expected to have to cope with sub-files vanishing at random
    (no more than they're expected to cope with a user doing 'rm
    directory/file' these days)

    - EAs could be implemented as a sub-file using structured storage, but not
    the other way around - and even if they were, this is an implementation
    detail that should *never* be relied on.

    - Structured storage looses usefulness on an OS not built for it (Anybody
    remember Microsoft's plans for Cairo, aka Windows 2000, and the Object
    Filesystem they were going to implement?), because applications taking
    advantage of it loose portability. Wheras EAs can be enabled/disabled at
    compile time without massive losses in functionality, the the same
    doesn't really apply to SS, where if you're going to use it, you go
    the whole hog or not at all.

    I'll shut up now. :)

    --
    Mo McKinlay Chief Software Architect inter/open Labs
    -------------------------------------------------------------------------
    GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>








    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:0.024 / U:241.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site