simon@alberta.uucp (Simon Tortike) (02/19/89)
I use Suitcase II and TeXTures a lot. Both these programs have lots of
open files: Suitcase has font, da, and fkey files, Textures has several
font files and input files. When operating Textures I frequently
encounter the maximumum files are open error. As I have a Mac IIx with
8 Mbytes of RAM, it is annoying to have to close all my other programs
running under MultiFinder.
I have combined as many files as I want to (several font files for
Textures are of the order of 4.5 Mbytes), and want to know if I can
raise the limit on the number of open files without any unwanted side
effects. Further, is all I have to do is change the number in the max.
open files field in the boot blocks of the hard disk? This is apparent
when using a disk editor such as FEdit+.
Thanks,
-------------------
Simon Tortike, Department of Mining, Metallurgical and Petroleum Engineering,
The University of Alberta, Edmonton, AB, CANADA T6G 2G6.
simon@alberta.uucp || Tel. +1 403 492-3338dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (02/19/89)
In article <2054@pembina.UUCP> simon@alberta.UUCP (Simon Tortike) writes: >effects. Further, is all I have to do is change the number in the max. >open files field in the boot blocks of the hard disk? This is apparent >when using a disk editor such as FEdit+. I've had no problems doing this, but I have a 2 meg machine so the extra file buffers in memory probaably don't impact on my memory usage as much as it would on a 1 meg machine. I can't think of any other changes that would need to be made, but after doing it I'd watch your system and change it back if you notice any problems. Also if you ever create a system disk for a friend by draging a system/finder onto a floppy I believe the finder copies the current {ie. your hard drives boot blocks} boot block on their floppy. The reason I mention this is that they might not want to allow that many files to be open on their system. ONe last thing, I can't help but think that apple set that limit for a reason, could anyone from Apple give us in netland a summary of what the exact ramifications of changing the max files is, like I said I've had no problems so far, but then again I might be a special case. -- David M. O'Rourke dorourke@polyslo.calpoly.edu "If it doesn't do Windows, then it's not a computer!!!" Disclaimer: I don't represent the school. All opinions are mine!
kent@lloyd.camex.uucp (Kent Borg) (02/23/89)
In article <8219@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: >In article <2054@pembina.UUCP> simon@alberta.UUCP (Simon Tortike) writes: >>effects. Further, is all I have to do is change the number in the max. >>open files field in the boot blocks of the hard disk? This is apparent >>when using a disk editor such as FEdit+. > > I've had no problems doing this, but I have a 2 meg machine so the ... > Also if you ever create a system disk for a friend by draging a system/finder >onto a floppy I believe the finder copies the current {ie. your hard drives >boot blocks} boot block on their floppy. The reason I mention this is that ... I haul my hard disk between a small RAM machine and a big RAM machine and I have some problems. If I configure it so I can use the big machine well, I can't even use paint tools in HyperCard when on my small machine. I think Apple set the number to be a compromise between `too small for you' and `too big for him'. If you want to change it, give it a try. From the default 10 files to 25 seems just fine for the big machine, but is very tight for the little machine. Kent (Who wishes he owned a big machine) Borg kent@lloyd.uucp or hscfvax!lloyd!kent
alexis@ccnysci.UUCP (Alexis Rosen) (02/24/89)
David O'Rourke says that changing the maximum number of files open, as spec'd in the boot blocks, seems to be OK but is unsanctioned. I have done this on many machines for a long time and have never noticed any problems. I would go out on a limb and say that there is NO effect, other than reducing slightly the amount of available RAM. David also warns that the current boot blocks are copied onto disks formatted by the system. This is definitely true. However, I have a question about this. If you look in the System File you will notice a 'boot' resource. This resource contains an image of the boot blocks. Is this the source from which newly-initialized disks get their boot blocks, or do they come from the actual b.b. of the boot disk? If the latter, what purpose does that resource serve? Alexis Rosen alexis@ccnysci.uucp
alexis@ccnysci.UUCP (Alexis Rosen) (02/26/89)
Something *VERY* screwy is going on here. I just looked at the boot blocks on my two and they unquestionably say, ten open files. Well, that's a little weird. See, I'm running MultiFinder. And when I work, I usually have the Finder, Word, FoxBase, and sometimes ResEdit and LSP all open at once. In Foxbase alone I can have twenty or thirty files open at once. Now it's true, some of those are text files which are probably read and then closed, but as I type this I have six data files and eleven indexes open! Now, I just tried to open lots of files in ResEdit and I hit a hard limit of three open files. I know that I've had more than that open at once in the past. So is that open-file limit applicatble to _resource_ files only? If so I've been wasting some memory (not a lot, though). That does bring up another question though- what does the file system do about open data forks? Does it just allocate the buffer (if you don't allocate your own) and other stuff on the system heap? What gives? Alexis Rosen alexis@ccnysci.uucp
korn@anableps.berkeley.edu (Peter "Arrgh" Korn) (02/27/89)
In <1329@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) said: >Something *VERY* screwy is going on here. I just looked at the boot blocks on >my two and they unquestionably say, ten open files. Well, that's a little >weird. See, I'm running MultiFinder.... Not screwy at all, when you think about it. MultiFinder has to play a number of games behind-the-scenes in order to work as well as it does. One of these is to look at the number of files that can be opened at once listed in the boot blocks and, when MultiFinder is running, increase that number by some factor so that people don't run into unexpected problems that they themselves cannot correct and don't understand (I can just imagine trying to explain "boot blocks" to my mom, who just recently managed to use MacPaint for a drawing of hers [yea mom!!]). >Now, I just tried to open lots of files in ResEdit and I hit a hard limit >of three open files. I know that I've had more than that open at once in >the past. So is that open-file limit applicatble to _resource_ files only? >If so I've been wasting some memory (not a lot, though). What sort of error message did you get using which version of ResEdit under which version of the OS when this happened? Peter -- Peter "Arrgh" Korn korn@ucbvax.Berkeley.EDU {decvax,hplabs,sdcsvax,ulysses,usenix}!ucbvax!korn
brecher@well.UUCP (Steve Brecher) (02/28/89)
In article <1329@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) writes: > Something *VERY* screwy is going on here. I just looked at the boot blocks on > my two and they unquestionably say, ten open files. Well, that's a little > weird. See, I'm running MultiFinder. And when I work, I usually have the > Finder, Word, FoxBase, and sometimes ResEdit and LSP all open at once. In > Foxbase alone I can have twenty or thirty files open at once. The number in the boot blocks is multiplied by 4 prior to use, so you have 40 FCBs. The quadrupling is for historical reasons; on 128K Macs, the number was used verbatim. Other posts have asked about the cost of increasing the number in the boot blocks. The RAM cost is currently 94 bytes per FCB. The FCB table is allocated in the system heap by ROM startup code. The maximum number of FCBs that is currently possible is 348 (boot blocks value of 87), since the size of the FCB table must be less than 32K. > That does bring up another question though- what does the file system do > about open data forks? Does it just allocate the buffer (if you don't > allocate your own) and other stuff on the system heap? What gives? Data and resource forks are more or less the same to the file system. No buffers are allocated upon opening a file; if the caller doesnUt specify his own buffer, the volumeUs buffer is used for file I/O. The volume buffer is allocated in the system heap when the volume is mounted. -- brecher@well.UUCP (Steve Brecher)
alexis@ccnysci.UUCP (Alexis Rosen) (02/28/89)
In article <10408@pasteur.Berkeley.EDU> korn@anableps.berkeley.edu (Peter "Arrgh" Korn) writes: >In <1329@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) said: >>Something *VERY* screwy is going on here. I just looked at the boot blocks on >>my two and they unquestionably say, ten open files. Well, that's a little >>weird. See, I'm running MultiFinder.... > >Not screwy at all, when you think about it. MultiFinder has to play a number >of games behind-the-scenes in order to work as well as it does. One of >these is to look at the number of files that can be opened at once listed >in the boot blocks and, when MultiFinder is running, increase that number >by some factor [etc.] Hm. I've read that Tech Note too, I think. >>Now, I just tried to open lots of files in ResEdit and I hit a hard limit >>of three open files. >What sort of error message did you get using which version of ResEdit under >which version of the OS when this happened? Um. The same version that just opened thirteen files with no problems. I guess I'm going to have to do a bit more exploration. 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... Alexis Rosen alexis@ccnysci.uucp
brecher@well.UUCP (Steve Brecher) (03/01/89)
In article <10408@pasteur.Berkeley.EDU>, korn@ucbvax.Berkeley.EDU (Peter Korn) writes: > MultiFinder has to play a number of games behind-the-scenes in order to work > as well as it does. One of these is to look at the number of files that can > be opened at once listed in the boot blocks and, when MultiFinder is running, > increase that number by some factor so that people don't run into unexpected > problems... Not true. Well, maybe "play a number of games" is true, but the part about increasing the number of simultaneously openable files (aka FCBs, File Control Blocks) is not true. -- brecher@well.UUCP (Steve Brecher)
brecher@well.UUCP (Steve Brecher) (03/02/89)
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)