lkml.org 
[lkml]   [2000]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: NTFS-like streams?
    On Sun, 13 Aug 2000, Mo McKinlay wrote:

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

    Is structured storage really a kernel issue? I'd have said the kernel
    should treat such files as normal files, then userspace is responsible for
    handling the contents.

    > - 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.

    Yep. ==> EA's are *NOT* directory-like in any way.

    > - 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.

    Yep. Not sure we need S_COMPLEX - with my solution, the existence of EAs
    is obvious without any API changes.

    > - 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)

    file:EA-name, yes. file/EA-name, no - they are NOT directories, and
    shouldn't try to look like one. That way lies breakage, surprises and
    nastiness.

    > - 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)

    No need for a new call: just "ls file:*" to list the EA's attached to
    "file". opendir() should certainly fail - it's not a directory in any way.

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

    Yep. My approach has the advantage you can get "EA's" via ext2 etc without
    any change in API - cp WILL copy the EA's attached to a file, making them
    into files in their own right. Copy the files back to NTFS, they revert to
    being EAs.

    > - Access permissions of EAs could either inherit totally from the file
    > associated with them.

    I'd go with that. That's how NTFS does it, too.

    > 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.
    Yep.

    > * 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).
    Hrmm... Supposing the EA is the thumbnail for an image? If you aren't
    allowed to read the image itself, do you want the thumbnail readable??

    > * You cannot remove/rename an EA unless you can write to the associated
    > file.
    Hrm. Either that, or handle it in the same way as for deleting the file
    itself: write permissions to the parent directory.

    > * You cannot list EAs unless you can read the file (not sure about the
    > point of this one, but it seems logical).
    Ehm... hang on. If I have read access to a directory, and no access to a
    file in that directory, I should be able to READ the EAs of that file -
    but not LIST them?!?!

    > 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).

    I'd just treat the EA's like the file's main data attribute. On an FS
    level, all the attributes are equal - why treat them differently at
    user-level?


    James.


    -
    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:2.273 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site