CCed to openxdsm because we need extended attributes and Hans Reiser
because I know he has comments but didn't reply to your mail.
On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
Hello,
This is a proposal to add extended attributes to the Linux kernel.
Extended
On Tue, 24 Oct 2000, Ragnar Kjørstad wrote:
On Sun, Oct 22, 2000 at 04:23:53PM +0200, Andreas Gruenbacher wrote:
Hello,
This is a proposal to add extended attributes to the Linux kernel.
Extended attributes are name/value pairs associated with inodes.
A patch implementing extended
"Stephen C. Tweedie" wrote:
Hi,
On Tue, Oct 24, 2000 at 09:20:05AM +0200, Ragnar Kj?rstad wrote:
I don't know how much need there is for inheritence here, but if a lot
of attributes will need it I think it should be supported in the
interface instead. (though hardlinks really make
On Tue, Oct 24, 2000 at 01:46:49PM +0100, Stephen C. Tweedie wrote:
Shure there should be lowlevel access to the eas for user-EAs or some
special cases, but for the main usages (ACLs, Filesystem Capabilities,
MACs) there should be a special high-level API instead.
So instead of using the
Hi,
On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote:
Why do you force the user to copy the data into the attrib structure, rather than
letting him leave
the data where it lies and simply specify the location to the kernel?
In the first draft of the API put together, I did in
"Stephen C. Tweedie" wrote:
Hi,
On Wed, Oct 25, 2000 at 09:09:57AM -0700, Hans Reiser wrote:
Why do you force the user to copy the data into the attrib structure, rather than
letting him leave
the data where it lies and simply specify the location to the kernel?
In the first draft
Hi,
On Wed, Oct 25, 2000 at 08:45:28AM -0700, Hans Reiser wrote:
Extended attributes should be accessed by an interface that accesses them as files
with a particular
name.
That is a good goal, but it breaks down in some cases.
There already exist filesystems where named streams and named
