[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Named streams, Re: Cleaning up namei
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
Main Index |
Thread Index |