> 
> On Sat, Aug 25, 2001 at 09:36:37PM -0400, Ken Cross wrote:
> > How it's stored on disk is implementation-dependent and varies considerably.
> 
> Which, it seems to me, is the only remaining question bearing debate
> on tech-kern.
> 
> FFS does not seem to have bits free for this. Certainly not for a
> plausibly infinite block of metadata (well, okay, you couldn't have
> more than 65536*2 sets of credentials, but that's a lot of bits).
> And (imho) it belongs at the UFS layer anyway, so that we get it
> in other file systems. (Yes, I have a specific LFS disk in mind
> where I want ACLs, thanks for not asking.)
> 
> So, then, what can we do to allow an ACL-aware kernel to still
> behave correctly with an old-style {F,U}FS partition (that's the
> easy part), and what can we do to make a non-ACL-aware kernel able
> to read a file system with ACLs (that's the hard part).
> 
> In my opinion, there's no need for the second part.

Oops, I use ffs filesystems on removable media so there is an immediate
need for the second part. Is it possible to use a fixed inode for the
acl database?

> As long as
> install media sticks to the old style (and why shouldn't it? Look at
> Apple and HFS versus HFS+ in MacOS 8 and 9), the only time I'm
> going to pop a disk with ACLs into a machine that doesn't have them
> is when I'm doing some kind of data recovery. And I can deal with
> building a kernel for that. (Well, actually, I'll probably never
> stick a disk with ACLs into a machine without, as I'll probably use
> them everywhere, as I know how much better a system they are having
> used them under Solaris. But whatever.)
> 
> What's really lacking is anyone with the knowledge, time, and
> interest to make this happen. I'm short at least one of those at
> present myself.
> 
> -- 
>        ~ g r @ eclipsed.net
> 


-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)