On Thu, Mar 20, 2008 at 02:26:19AM +0000, David Holland wrote: > On Wed, Mar 19, 2008 at 02:12:36PM -0700, Bill Stouder-Studenmund wrote: > > One thing that would be good to support is one of the tricks that HFS will > > pull, which is that to open a named stream, you add "/streamname" to the > > end of a name. I think the only thing we need to support for this is that > > VOP_LOOKUP will tell us, "This was the last name component, even though > > you didn't think it was." I don't think this will impact namei_parent() > > though, as you don't "create" these forks, you add them to existing files. > > 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 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. Take care, Bill
Attachment:
pgpMXDewngC9k.pgp
Description: PGP signature