Ref: 10710056 Title: Data and resource forks, file sizes, etc. for the Mac Date: 7/7/88 Copyright 3Com Corporation, 1991. All rights reserved. Q: Why do folders grow in size when you copy them to the server? Is it because of the hidden MacFS files? A: The factor that accounts for the greatest differences in consumed disk space is the minimum allocation block size for a particular diskette, hard disk, or server partition (in the case of our shared folders). The default allocation block size on 3Servers is 2K; this is the DOS "cluster" size. On Mac 3.5" disks it is 512 bytes. The amount varies on Mac hard disks. For large disks, larger allocation block sizes are used to prevent fragmentation and to keep the tables that manage all these pieces to reasonable sizes, such as the DOS "FAT" tables on 3Com servers and the hidden HFS catalog files on Macintosh disks. (Note that empty 800K floppies are never 800K.) For very small files, you can see big differences. A simple text file containing 50 bytes of data will take up 512 bytes on a diskette, but will consume 2K on a 3Server. If the file had a resource fork of 200 bytes in length, the file would consume 1K on diskette and 4K on a 3Server. Each fork is allocated disk space independently and in the case of 3Servers each fork of a Mac file is a separate DOS file. It is correct to recognize that the hidden MacFS database files consume space. The MACDIR files that are present in every directory used by Mac clients will add some to this difference. There will be a record in this file for every Mac file in the directory. These records vary from 108 to 108+199 bytes in size (199 is max Getinfo comment length). There can be up to an extra 1K of logically deleted space in these files before they will be compressed to just valid entries. The APPL file (one per home folder) contains 170 byte records, one for every Mac application within the root or any subfolder of the Home Folder. The ICON file (one per home folder) generally contains records of a length of about 530 bytes, one for every ICON found by the Finder in every application within the root or any subfolder of the Home Folder. The MDIRID file (one per home folder) contains records of up to 100 bytes long, one for every Mac folder in the Home Folder or its subfolders. The MACVOL file (one in every folder for which there is a sharename) consumes 330 bytes. ----------------------------------------------------------------------- Q: Isn't it true that two forks are created no matter what and therefore a 20 byte data fork file would take up 4k on the server? A: There is always a data fork file, even if there is no data. Data fork only files will not have a resource fork created unless the resource fork is opened. The wasted fork is most commonly seen with Mac applications, most of which have no resource forks. These will appear in DOS directory listings as 0 length files. Other examples of files in this category are those created by Font/DA Mover (presumed) and ResEdit. The reason a data fork is always created is partly due to MacFS architectural design as well as to make the existence of all Mac files visible to DOS clients. The files representing the resource forks on the server have the system attribute set to hide them from DIR and DEL type commands. A data fork is present for every Mac file so that DOS clients are aware of the existence of Mac files via a single directory entry. The Mac Database files that appear in the directories also have the system attribute set. When the MacFS has to return a list of all the files in a particular directory to a Mac client, it has to come up with a list of names that maps one-to-one with actual files. It asks CIOSYS for all DOS dirs and files in the directory, except those files that have the system bit set. This will filter out the MacFS database files and only return one entry for 2 fork files (the data fork). Then for each of the entries returned, a search of the MACDIR file occurs to see if the file or directory has Mac attributes associated with it. If so, then those attributes are returned; otherwise default attributes are supplied (the latter case happens when a Mac opens a DOS directory for the first time or if a DOS client adds an entry to a Mac folder).