--6e7ZaeXHKrTJCxdu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2005 at 10:16:33PM +0200, Reinoud Zandijk wrote:
> Hi,
>=20
> On Tue, Jun 28, 2005 at 10:54:34AM -0700, Jason Thorpe wrote:
> > On Jun 28, 2005, at 6:28 AM, Reinoud Zandijk wrote:
> > >yup...  though i have a similar naming problem as has HFS+. On UDF =20
> > >a file
> > >can have an associated streamdir with it basicly turning it into a
> > >composite of a file and a directory with named streams. Directories =
=20
> > >though
> > >can also have an associated streamdir with it. (!)
> >=20
> > Yah, this is done in Mac OS X on HFS+ file systems like so:
> >=20
> >     /path/to/regular/file
> >     /path/to/regular/file/..namedfork/data    <- equivalent to first =
=20
> > example
> >     /path/to/regular/file/..namedfork/rsrc    <- Mac OS X "resource =20
> > fork"
> >=20
> > This is handled by the HFS+-specific lookup routine.
>=20
> So they are listable? and a directory then represented like=20
> /path/to/regular/directory/..namedfork/* ?

No, nor should they be. The file listing is of files, not parts of files.=
=20
Thus they don't belong. :-)

> Is the "..namedfork" name a constant name?

For HFS(+), yes.

> > It should be pretty straight-forward to encapsulate this type of sub-=
=20
> > file handling into the file system itself... OTOH, it might map =20
> > pretty well to what Gordon wants with openat() and friends.
>=20
> hmmm... openat() could be used for the streamdirs but isnt openat() a=20
> generic relative adressing way?
>=20
> For the extra time attributes that might be handy i'll think of a=20
> VOP_{GET,SET}TIMES() proposal wich shouldn't be to hard to implement.

Use VOP_FCNTL(). AFAICT it already does what you need to get a call from=20
userland to the file system.

Take care,

Bill

--6e7ZaeXHKrTJCxdu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCwfOQWz+3JHUci9cRAiOrAJ9nlaWYNsmEtiT5gH5Ntfd8omszqQCgjVrO
ql4L9SkfZhE3/r3vp0K0mVA=
=fRnH
-----END PGP SIGNATURE-----

--6e7ZaeXHKrTJCxdu--