Re: Named streams, Re: Cleaning up namei

[Dieter Baron <dillo%KD119105101110.ppp-bb.dion.ne.jp@localhost>]

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 
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. ;-)

  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.


                                        yours,
                                        dillo