[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Named streams, Re: Cleaning up namei
In article <20080321014502.GA5532%netbsd.org@localhost> Bill wrote:
: [-- text/plain, encoding quoted-printable, charset: us-ascii, 44 lines --]
: 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
: > > 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
: > > 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
: > 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. ;-)
What Mac OS X still does, is use this syntax to access a file's
resource fork. Our HFS+ implementation already supports this, and it
would be nice if that were still possible.
The only operation supported is open(2). You can't remove the
resource fork (every file has a (possibly empty) resource fork), you
can't rename it, you can't create other forks.
Main Index |
Thread Index |