[lkml]   [2000]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NTFS-like streams?

    This is a file system dependent issue and it should be up to each file
    system how they implement this. The ~ ideas had some merit, but the
    FS's still need to know when attributes are being read and written to
    map well to those FS's that can support this (and EXT2 could be one of
    them). The best general purpose way I can think of through the VFS (not
    to say there are not other approaches) is to implement an indirection
    structure within the functions that manage inodes, i.e. read_inode,
    write_inode, etc.
    add a structure pointer to a table of function that support named
    attributes, such as

    attr_opns: <filesystem>_attr_opns

    which just indirects to another table with semantics a lot like:

    attr_open: int attr_open(struct inode *f_inode, struct dentry
    struct inode **result, int flags, int mode);
    // return inode for attr file in *result
    attr_close: int attr_close(struct inode *attr);
    attr_unlink: int attr_unlink(struct inode *dir, struct dentry
    attr_create: // the rest are standard linux file opns calls

    The real question here is do we want to waste an inode on one these
    attribute chains, but may have to since named external attributes do
    have a filesize. There's also a question of permissions. One thing
    Linux could do to improve on the NTFS attriute model is to add fine
    grained security to individual file attributes.




    John Franklin wrote:
    > On Mon, Aug 14, 2000 at 05:30:59PM -0000, Christer Weinigel wrote:
    > > wrote:
    > > > I read it as "If it can be supported in a sane way, we should do it". This
    > > > is insane, as are all the other schemes I've seen discussed here. And
    > > > "supported somehow" leaves a lot of non-kernel options open: Special tools,
    > > > a compatibility library, ...
    > >
    > > So what is the sane way? There are three conflicting requirements for
    > > NTFS-like streams handling:
    > >
    > > 1. Don't break any existing tools, everything must behave exactly as
    > > it does today. tar must be able to make a complete backup.
    > >
    > > 2. Should allow old tools to work on the alternate streams (i.e.
    > > xv file/thumbnail.xpm).
    > >
    > > 3. Should not pollute the filesystem with extra files such as
    > > .AppleDouble, .fork, foo:resources or foo#tar/altstream.
    > (1) and (2) are things we can support in the VFS layer. (3) is
    > filesystem specific and, as such, is beyond the scope of this
    > discussion, IMHO. We are attempting to find a way of supporting
    > EA/NS in Linux itself so that the NTFS/HFS/BeFS functionality can
    > be fully supported in an independent manner.
    > > Another way is to implement a completely new API to access streams,
    > > for example:
    > > open_stream(fd, name) which returns a file descriptor
    > > create_stream(fd, name) which returns a file descriptor
    > > remove_stream(fd, name)
    > > enumerate_streams(...) which is similar to opendir/readdir
    > Linus suggested something like this with some trivial name changes.
    > This is, I thin, pretty close to what we're going to need when all
    > is said and done. This would allow a number of FS implementations to
    > work with the Linux kernel.
    > > This would work with no 1 and 3 - would not confuse any existing tools
    > > with a file/directory duality, but would also break no 2 by not
    > > allowing existing tools to work with the alternate stream data. And
    > > if one looks at the above functions, they are just a duplication of
    > > the normal open, create and opendir/readdir API's.
    > Part of the point of NS/EA is to allow programs that don't care about
    > them to use the files as they normally would, while allowing programs
    > that do know about them to exploit the extra functionality. As such,
    > making existing tools automagically work is probably not possible.
    > As Linus mentioned, tar can be extended. I'd go so far as to claim
    > the same for cp, mv, cpio, etc.
    > A Good Solution would, however, minimize the amount of extension
    > needed.
    > > but it has its problems with orphaning. The "different-API" model is
    > > clean, but means that just about every tool existing has to be
    > > rewritten to support alternate streams (for extended attributes, I
    > > belive this is the way to go, but for data streams it's not).
    > Building a clean, FS-independent interface is, IMHO, the way to go.
    > jf
    > --
    > John Franklin
    > Interlan Communications
    > ICBM: 35°45'17"N 78°44'11"W
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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