Technical Note FL520

File Manager Overview Q&As

CONTENTS Macintosh folder file limits Determining which Macintosh File Manager calls are available System 7.0 DAs and 'vers' resources Downloadables

This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&As can be found on the Macintosh Technical Q&As web site. [Oct 01 1990]

Macintosh folder file limits

Date Written: 11/9/92

Last reviewed: 6/14/93

What (if at all) is the limitation on the number of files in a folder? In other words, is there a number N, such that if I have N files in a folder, and I try to Create file number N+1, I'll get some error?

___

In general, the number of files that can be put in an HFS directory is unlimited; there isn't any point at which you'll receive an error from Create, because new file description records can almost always be created. The only way you can get a disk full error back from Create is if the catalog file needs to grow to add your new record and the disk is full, but this should be extremely rare; even when the disk is full, there's generally room to create dozens of files or folders before the catalog file will need to be enlarged, as it's grown in relatively large chunks.

There are, however, a couple of related limits on large numbers of files. Because HFS allocates space in "allocation blocks," and there can be at most 65,536 allocation blocks on a volume, there's a limit of 65,536 files that contain data on a volume. If your disk is full with 65,536 one-block files, you'll probably be able to create more files (Create will succeed), but no data will be able to be written to them. In reality, the limit on the number of files is somewhat smaller; the catalog and extents files will each occupy space. Also, because the allocation block size needs to be an even multiple of 512 bytes, most volumes won't have a full 65,536 allocation blocks; they'll have as many as they can, somewhere between 32,767 and 65,536 (except for small volumes, which may have less). In addition, each fork (either the data fork or the resource fork) of a file needs to be separately allocated, so each counts as a file for this calculation.

There's also a practical limit on how many files can be placed in a folder. HFS can maintain as many files as required in a directory; however, because the index field is a short, if there are more than 32,767 files in a folder, they can't be enumerated. Thus, while they can be identified and opened by name, there's no way to index through them to determine what's in the directory without deleting or moving some of the files.

These limit descriptions apply to HFS only; other file systems may be available on the Macintosh, such as MFS, MS-DOS, ISO 9660, or virtually any file system via an AppleTalk Filing Protocol (AFP) translator. These descriptions also don't include limitations of the Finder, the Standard File Package, or any other intermediaries. The Finder and Standard File are likely to become quite unusable long before you run into the limits of HFS. Also, while HFS will continue to function, it wasn't designed for optimum performance with extremely large numbers of files; for more dire warnings on this subject, see the Macintosh Technical Note "Don't Abuse the Managers."

Back to top

Determining which Macintosh File Manager calls are available

Date Written: 3/5/92

Last reviewed: 6/14/93

Many of the new File Manager calls are just _HFSDispatch with new selector codes. How do I check whether a given selector is implemented? An example of a new File manager call is _GetVolParms. Currently I don't check, I just read the result code. It seems to be OK. How should I interpret the response from Gestalt when called with gestaltFSAttr? As I read it the gestaltFullExtFSDispatching tells me that all the calls are available. Are there times that only a few of them are available? PBHGetVolParams seems to be available at all times anyway. Where do I find more info on the workings of HFSDispatch? In general I would appreciate some more info on the compatibility issue.

___

There are two issues. One is that not all versions of the File Manager support all calls. The other is that even if the File Manager supports the calls, individual volumes may not.

The first issue is addressed by Gestalt's gestaltFSAttr selector. Prior to System 7.0, HFSDispatch supported a fixed range of selectors. The result was that some advanced file services were unavailable, even though the volume would support them. A good example is PBCatSearch. If you mount an AppleShare 3.0 or FileShare volume under System 6 with the AppleShare 3.0 Chooser extension, the volume will report via PBHGetVolParms that bHasCatSearch is true. But if you try to make the call, you will get back a paramErr because HFSDispatch doesn't know about the CatSearch selector.

Under System 7.0, the system no longer restricts the range of HFSDispatch selectors. For external file systems, this means it is up to the external file system to determine whether or not it can handle the selector and to return an appropriate error if it cannot.

This is the meaning of the gestaltFullExtFSDispatching flag. If it is true then there are no limitations on the range of selectors.

The second problem is that even though HFSDispatch won't limit the range of selectors, the volume may still not support the call. To turn my previous example around, making a PBCatSearch call under System 7.0 to a pre-AppleShare 3.0 volume will result in an error because the volume doesn't support the call.

The best way to determine if a volume supports a feature is to use PBHGetVolParms. This can return most of the information you need about advanced file system calls. Unfortunately, there can be problems, even with that. For example, when the user turns FileSharing on and off, the bHasPersonalAccessPrivileges flag can change. So you can't just test attributes once and assume they never change.

As far as knowing whether PBHGetVolParms is available, this is not a new call. It is documented in the chapter titled "File Manager Extensions In a Shared Environment" in Inside Macintosh Volume V. The way to check for it is to simply call it and if you get back a paramErr, it is unsupported (IM-V-387). This seems to be what you are doing, so you should be safe.

So, to summarize, there is no guaranteed way to know if a particular selector will work (but it should never crash, just return paramErr). The right sequence of steps is to first check to see if HFS supports the full range of calls, then check for specific features using PBHGetVolParms. And in any event, you should always check for errors and be prepared to take appropriate action. A good example of how to do this can be found in the latest (January 1992) version of the Technote titled, "Searching Volumes--Solutions and Problems."

Back to top

System 7.0 DAs and 'vers' resources

Date Written: 9/3/91

Last reviewed: 10/8/91

Why does System 7 get rid of my 'vers' resources in my desk accessories when dropped into the System Folder icon?

___

The System 7 Finder takes over some of the job of the old Font/DA Mover program. The Font/DA Mover took great pains to keep all resources owned by the DA together with the driver resource. This is mentioned in the Macintosh Technical Note "Shortcut for Owned Resources," as well as in Inside Macintosh Volume I, page 109.

Under System 7, the 'vers' resource used for Finder information is not owned by the desk accessory, so when the Finder copies the desk accessory it skips the resources extraneous to the DA--including the 'vers' resource.

The simplest thing to do is to provide a System 7-ready version of your DA (see Inside Macintosh Volume VI, page 9-32). The Finder will not strip off resources if the file type is already 'dfil' when the DA is dragged to the System Folder. You can also provide a version of the DA in a suitcase for System 6, or you can instruct System 6 users to hold down the Option key while clicking Open in Font/DA Mover if they want to install your DA.

Back to top

Downloadables

Back to top