Re: Named streams, Re: Cleaning up namei

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Mar 20, 2008 at 06:45:02PM -0700, Bill Stouder-Studenmund wrote:
 > > Hmm. This is not entirely trivial, because for rename (and mkdir,
 > > etc.) you need to be able to tell which is the last component before
 > > trying to look it up.
 > 
 > I don't think so. mkdir, rename, and such don't need to work on named 
 > streams. In general, you can't rename named streams, and I think using an 
 > API other than unlink(2) to remove them is fine.
 > 
 > Mac OS used to have "complex" vnodes, which were files that had named 
 > forks. They acted like files, but you could do lookups on them. Mac OS no 
 > longer has them, so I consider them a dead experiment. ;-)

But there's no reason they should be prohibited by the VFS layer.

 > > But then again, for nearly all purposes, the fork name *is* the last
 > > component, and the file holding the streams *is* effectively a
 > > directory. So I suspect it'll all just work given implementations for
 > > the directory-like VOPs on multistream regular files. Provided the
 > > VFS-level code doesn't check the vnode type before calling directory
 > > ops, but in general it shouldn't be doing that - vnode types are all
 > > very well but they're not necessarily authoritative.
 > 
 > As above, HFS on Mac OS used to do that, but no longer does. Now it just 
 > gobbles up the last name on an open.

I think it will all work then, provided I don't lose my mind and add
an explicit test for vnodes being directories instead of relying on
VOP_LOOKUP to yield ENOTDIR.

If I do that, there are bricks :-)

-- 
David A. Holland
dholland%netbsd.org@localhost