Anton Altaparmakov wrote:
> 
> At 11:00 28/10/2000, Hans Reiser wrote:
> >Curtis Anderson wrote:
> >
> > > The problem with streams-style attributes comes from stepping onto the
> > > slippery slope of trying to put too much generality into it.  I chose the
> > > block-access style of API so that there would be no temptation to start
> > > down that slope.
> >
> >I understand you right up until this.  I just don't get it.  If you extend
> >the functionality of files and directories so that attributes are not
> >needed, this is goodness, right?  I sure think it is the right
> >approach.  We should just decompose carefully what functionality is
> >provided by attributes that files and directories lack, and one feature at
> >a time add that capability to files and directories as separate optional
> >features.
> 
> No, it is _not_ goodness, IMHO. - If you did implement the API for
> attributes through files and directories, then what would you do with named
> streams?!?
> 
> You can't possibly have both using the same API since you would then get
> name collision on filesystems where both named streams and EAs are
> supported. 

So: your challenge is 'come up with a way of handling at least two
different name spaces or forget it'?


> (And I haven't even mentioned EAs and named streams attached to
> actual _real_ directories yet.)

This at least is easy to deal with: embed the directory in another
directory and set the appropriate bit.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]

Reply via email to