> > > No, I disagree. Sticking a database in the inode sounds like a mess to me.
> > > And that is what you're proposing.
> > 
> > Putting in an opaque data field with flag bits sounds like a mess to
> > me.   Maybe this isn't a good argument.
> 
> Wait. The flag bits never were in the opaque data. They, and 28 unused
> bytes, were outside the opaque data.

I know that.

> > > And just what, exactly, are other people going to want to stick in here?
> > 
> > Other file attributes?   You're proposing a userland API - I can think
> > of things I'd like to stick in there.   Small things, obviously.   GUI
> > hints, for example.
> 
> Since we have only 128 bytes, starting down the road of storing GUI stuff
> here makes me nervous...

I would expect a typical GUI tag to consume eight bytes - four for the
magic number and length, and four for a type code.   There would be
one per file.   That's a lot more compact than your application!

> ACL's were never intended to be stored in the opaque data. I'm sorry that
> some folks gathered that impression.

Sure, but you could store a pointer to ACL information there.

The point I'm making by coming up with examples for uses of the opaque
data is that there _are_ uses for it.  There are reasons why it would
make sense to share it.  There is no significant additional cost to
making it sharable.  So let's make it sharable.

For some reason you seem to be defending your position at all costs,
as if you winning the argument were what was important.  Of course you
can come up with rhetorical ripostes to the examples I've shown, but
the examples aren't important.  What's important is implementing a
solution that works generally, not just for your particular
application.

			       _MelloN_