Subject: Re: CVS commit: src
To: Reinoud Zandijk <reinoud@netbsd.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/29/2005 09:22:16
--ABTtc+pdwF7KHXCz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2005 at 04:13:38AM +0200, Reinoud Zandijk wrote:
> On Tue, Jun 28, 2005 at 06:04:16PM -0700, Bill Studenmund wrote:
> > > So they are listable? and a directory then represented like=20
> > > /path/to/regular/directory/..namedfork/* ?
> >=20
> > No, nor should they be. The file listing is of files, not parts of file=
s.=20
> > Thus they don't belong. :-)
>=20
> really?

Yes. Mainly as if we start listing all of the files + sub extensions that=
=20
we can open, we can very quickly (in my opinion) lose ourselves in a messy=
=20
sea of file "names."

If we want to add some special way to ask a file system for the=20
open(2)able parts of a given file, that's fine. However if I do an ls of a=
=20
directory, I think it would be very useless to see all the named fork=20
appendates after the file names.

Which do you find more useful:

# ls /bin
[          csh        ed         ls         pwd        sh         test
cat        date       expr       mkdir      rcmd       sleep
chio       dd         hostname   mt         rcp        stty
chmod      df         kill       mv         rm         sync
cp         domainname ksh        pax        rmail      systrace
cpio       echo       ln         ps         rmdir      tar

or

[/..namedfork/data              mkdir/..namedfork/data
cat/..namedfork/data            mt/..namedfork/data
chio/..namedfork/data           mv/..namedfork/data
chmod/..namedfork/data          pax/..namedfork/data
cp/..namedfork/data             ps/..namedfork/data
cpio/..namedfork/data           pwd/..namedfork/data
csh/..namedfork/data            rcmd/..namedfork/data
date/..namedfork/data           rcp/..namedfork/data
dd/..namedfork/data             rm/..namedfork/data
df/..namedfork/data             rmail/..namedfork/data
domainname/..namedfork/data     rmdir/..namedfork/data
echo/..namedfork/data           sh/..namedfork/data
ed/..namedfork/data             sleep/..namedfork/data
expr/..namedfork/data           stty/..namedfork/data
hostname/..namedfork/data       sync/..namedfork/data
kill/..namedfork/data           systrace/..namedfork/data
ksh/..namedfork/data            tar/..namedfork/data
ln/..namedfork/data             test/..namedfork/data
ls/..namedfork/data


> > > 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.
> >=20
> > Use VOP_FCNTL(). AFAICT it already does what you need to get a call fro=
m=20
> > userland to the file system.
>=20
> we could define FCNTL's for that yes... see my other mails to tech-kern f=
or=20
> the alternatives of using attributes, though FCNTLs for what i had in min=
d=20
> on various times would we less intrucive. What are your thoughts about my=
=20
> proposals on tech-kern?

I'll look at them more and comment there.

Take care,

Bill

--ABTtc+pdwF7KHXCz
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCwsq4Wz+3JHUci9cRAhDKAJ9h3DbDgsXWOOFyw57Sqv6XGT+zygCeP0Wv
qGEcqJzVINAhCaudw3mvdlA=
=/Bz6
-----END PGP SIGNATURE-----

--ABTtc+pdwF7KHXCz--