Xref: utzoo comp.sys.mac:27634 comp.sys.mac.programmer:4829
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!well!brecher
From: brecher@well.UUCP (Steve Brecher)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: Re: Changing max. no. of files open at one time under Mac OS
Message-ID: <10867@well.UUCP>
Date: 1 Mar 89 22:27:14 GMT
References: <2054@pembina.UUCP> <8219@polyslo.CalPoly.EDU> <331@lloyd.camex.uucp> <1329@ccnysci.UUCP> <10408@pasteur.Berkeley.EDU> <1354@ccnysci.UUCP>
Reply-To: brecher@well.UUCP (Steve Brecher)
Organization: Software Supply, Sunnyvale, CA
Lines: 25


In article <1354@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) writes:

> My question still stands, though- what are those doohickeys (FCBs?) for?
> Data forks, Resource forks, or both? if both, do I use up two slots if I
> open both a file's data and resource forks? I had originally assumed that
> they were for the data fork only...

FCBs (File Control Blocks) are data structures in which the system keeps
information about the identity and status of an open file (fork).  An FCB is
used for each open fork.  An open file's (fork's) refNum (path reference
number) identifies an FCB.  The data and resource forks of a file are really
two files (potential open I/O paths) having the same name and sharing a
directory entry.  Each directory entry contains a disk locations/extents
record for each fork.  The File Manager records the "is a resource fork"
attribute in the FCB -- one bit in the FCB is used for this purpose --
because it must know which fork is referred to when directory-altering
operations occur or when the path is closed.  Otherwise the File Manager
doesn't care about the type of fork.  The Resource Manager (but not the File
Manager) knows the internal structure of resource forks; the Resource Manager
accesses resource forks via the File Manager, much as a database application
accesses the data fork of a database document.
-- 

brecher@well.UUCP (Steve Brecher)