On Thu, 29 Jul 1999 06:40:11 -0500 (CDT), Frederick Bruckman <fb@enteract.com> wrote:
> On Thu, 29 Jul 1999, Ken Nakata wrote:
> 
> > On Wed, 28 Jul 1999 11:53:34 -0700 (PDT), Bill Studenmund <wrstuden@nas.nasa.gov> wrote:
> > > On Wed, 28 Jul 1999, Ken Nakata wrote:
> > > > BTW, are netatalk and CAP different in treatment of the resource fork?
> > > > I vaguely remember CAP looks into .resource/file (or s/t like that)
> > > > for file's resource fork (my college uses CAP to export UNIX home
> > > > directories to Macs).  Oh, well.  I think I'm asking this question way
> > > > too early.
> > > 
> > > netatalk and CAP do treat the resource forks differently. Paul Hargrove's
> > > hfsfs will actually export the resource forks differently as per mount
> > > options. :-)
> > 
> > You mean, hfsfs exports the resource forks in either netatalk way or
> > CAP way?
> 
> To change the subject, one thing that annoys me about netatalk is that
> it creates an .AppleDouble/file for every single file, whether it has
> or had a resource fork or not. Does CAP not do that? What is CAP
> anyway? Is that the AppleServer?

CAP stands for Columbia Appletalk Protocol (I think).  It was
originally developed at (as name suggests) Columbia University, but I
think at some point Rutgers University (where I happened to go) took
away its maintenance.

As for your annoyance, I really don't know.

> > Well, anyway, that'll come in much later. We need a data-fork-only
> > implementation of hfs first, I guess.
> 
> If you tell the user to remember the HFS path before booting, then all
> that's needed is to access the raw partition, walk the directory btree
> to find the root node, walk the bitmap btree to construct the sector
> map, then pull the file out. Being able to list directories would be
> even nicer, but that's as far as it goes.

Um, with hfs layer, HFS partition would look to the user like any
other fs NetBSD has.  It will do all the above for you.  That's what
a filesystem is supposed to do.

Ken