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
*f_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
*dentry);
attr_create: // the rest are standard linux file opns calls
attr_read:
attr_write:
attr_fsync:
attr_truncate:
attr_permission:
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.
IMHO
:-)
Jeff
John Franklin wrote:
>
> On Mon, Aug 14, 2000 at 05:30:59PM -0000, Christer Weinigel wrote:
> > vonbrand@inf.utfsm.cl 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
> franklin@interlan.net
> 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 majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:34 EST