"Stephen C. Tweedie" wrote:
>
> 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 atomic
> attributes both already exist. We need to differentiate between them.
Why? Just constrain the stream I/O for atomic attributes to be an error unless the
I/O overwrites
the entire I/O. Maybe I need to be more precise in my disagreement and it will cease
to be a
disagreement. Let's make atomicity a separate orthogonal feature.
>
> There already exist attributes which cannot be made into a stream,
> because we simply don't have access to the raw bits of the attribute
> --- for example, ACLs on networked filesystems.
>
> There exist attribute streams where the user may have write access to
> some sections but not others --- again, ACLs spring to mind.
>
> There exist attribute streams where we want type information to be
> passed: the example of POSIX ACLs using authentication tokens other
> than uid/gid is a good example, as Samba really wants to be able to
> set up native ACLs with NT SIDs as identifiers.
>
> Accessing extended attributes as if they were files is a useful API,
> but there are structured attributes where we really need better
> control over what is going on.
>
> I'm not saying that we can't expose the extended attributes as files,
> too --- just that such an API isn't sufficient for all cases.
>
> Cheers,
> Stephen
You are restricting the general case to serve the special case. Make atomicity an
orthogonal
restriction. There are apps which would like to atomically update arbitrary file
bodies not just
file attributes..... by making atomicity an orthogonal feature applicable to both
file bodies and
file attributes you gain. Yes?
Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
