Extended Attributes
| This section describes resource forks, file attributes, and ACLs, which are collectively known as extended attributes. Resource forks and file attributes are native to the HFS+ filesystem. Mac OS X emulates resource forks and file attributes on other types of filesystems. These features are not found on traditional UNIX filesystems. Caution: Some utilities do not process extended attributes Some third-party programs and most utilities under Mac OS X 10.3 and earlier do not support extended attributes. Some utilities require options to process extended attributes. Some utilities, on systems with ACLs enabled, have a bug involving extended attributes. For more information see the "Enabling ACLs may cause errors" caution on page 98. See also the "Redirection does not support resource forks" tip on page 94. File ForksForks are segments of a single file, each holding different content. Mac OS has supported file forks since its inception. The most widely used are the data fork and the resource fork. Data forks The data fork is equivalent to a traditional UNIX file. It consists of an unstructured stream of bytes. Many files have only a data fork. Resource forks A few files have only a resource fork. The resource fork holds a database that allows random access to resources, each of which has a type and identifier number. Modifying, adding, or deleting one resource has no effect on other resources. Resource forks can store different types of informationsome critical and some merely useful. For example, a Mac OS graphics program might save a smaller copy of an image (a preview or thumbnail) in a resource fork. Also, text files created with the BBEdit text editor store display size and tab stop information in the file's resource fork. Because this program is a text editor and not a word processor, this type of information cannot be stored in the data fork. Losing a resource fork that holds a thumbnail or display information is at most an inconvenience because the thumbnail can be regenerated from the original image. Other programs store more important data in the resource fork or create files that contain only a resource fork, which contains all of the file's information. In this case, losing the resource fork is just as bad as losing the data fork. It may even be worse: You may not notice when a resource fork is missing because the data fork is still there. You might notice the loss only when you try to use the file. A traditional UNIX filesystem associates each filename with a single stream of bytes. Forks do not fit this model. As a result, many UNIX utilities do not process resource forks but process only data forks. Most of the file utilities provided with OS X 10.4 and later support resource forks. Many third-party utilities do not support resource forks. Caution: Redirection does not support resource forks When you redirect input to or output from a utility (page 122), only the information in the data fork is redirected. Information in the resource fork is not redirected. For example, the following command copies the data fork of song.ogg only: $ cat song.ogg > song.bak.ogg In a similar manner, pipes do not redirect information other than that in the data fork.
If you are unsure whether a program supports resource forks, test it before relying on it. Make a backup copy using the Finder, ditto, or, under version 10.4 and later, cp. Then try the program you want to test; for example, use it to make a copy of your test file. You can then check whether the modified or copied file works correctly. Table 4-2 lists utilities that manipulate resource forks. These utilities are installed with the Developer Tools package. Consult the respective man pages for detailed descriptions.
File AttributesA file contains data. Information about the file is called metadata. Examples of metadata are ownership information and permissions for a file. Mac OS X stores more metadata than other UNIX and UNIX-like systems store. This section discusses file attributes, the metadata stored by Mac OS X. File attributes include the following items:
The same caveats apply to file attributes as apply to resource forks: Some utilities may not preserve them when copying or manipulating files, and many utilities do not recognize attribute flags. Loss of file attributes is particularly common when moving files to non-Macintosh systems. Attribute FlagsAttribute flags (Table 4-3) hold information that is distinct from traditional UNIX permissions. Two attribute flags are the invisible flag (which keeps a file from being displayed in file dialogs and in the Finder) and the locked flag (which keeps a file from being modified). Flags are generally ignored by utilities and affect only applications. The ls utility lists files that have the invisible flag set. See GetFileInfo on page 749 and SetFile on page 834 for information on displaying, setting, and clearing attribute flags. Some of the flags in Table 4-3 are meaningful only under Mac OS 9 and earlier and have no effect under Mac OS X.
Type Codes and Creator CodesType codes and creator codes are 32-bit integers, generally displayed as 4-character names, that specify the type and creator of a file. The creator code specifies the application that was used to create a document, not the user who created it. An application can typically open documents that have the same creator code as the application, but not documents with other creator codes. Creator codes generally correspond to vendors or product lines. The operating systemand in particular the Finderuses creator codes to group related files. For example, the AppleWorks application file and its document files have the creator code BOBO. In the file browser in an application's open file dialog box, grayed-out files generally indicate files that have a different creator code from the application. Finally, the open utility (page 803) looks at creator codes when it opens a file. Type codes indicate how a file is used. The type code APPL indicates an application, a program used to open other files. An AppleWorks word processor document has the type code CWWP, a mnemonic for Claris Works Word Processor (AppleWorks used to be named Claris Works). While a few type codes, such as the application type, are standardized, vendors are free to invent new type codes for their programs to use. A single application may support several document types. For example, AppleWorks supports spreadsheet files (CWSS), word processor documents (CWWP), and drawings (CWGR). Similarly a graphics program will typically support many document types. Data files used by an application may also have the same creator code as the application, even though they cannot be opened as documents. For example, the dictionary used by a spell checker cannot be opened as a document but typically uses the same creator code as the spell checker. Filename extensions Filename extensions (page 75) can substitute for type and creator codes. For example, an AppleWorks word processor document is saved with an extension of .cwk. Also, if open cannot determine which application to use to open a file using the file's creator code, it reverts to using the file's filename extension. Access Control ListsAccess Control Lists (ACLs), introduced under Mac OS X 10.4, augment standard UNIX file permissions by allowing you to control file access on a per-user or per-group basis. An ACL is an extended attribute (page 93) that holds access rules, each of which grants or denies file access to a user or group. You can give as many users or groups read, write, and/or execute access as you desire. ACLs may not work on a network (remote) filesystem depending on whether the remote operating system supports OS X ACLs. One use for ACLs is to control access to system files. For example, you could give Max and Zach read and write access to the message of the day file (/etc/motd) so that either of them could maintain it. You would not have to set up a special group or give write access to the public, as you would on a traditional UNIX system. Security: Grant permissions to root-owned files selectively Grant write and execute access to files owned by root with care. You are giving a user the ability to do things that root normally does. Keep a log of your ACL permission assignments. Enabling and Disabling ACLsUnder Mac OS X, ACL support is not enabled by default. You must use fsaclctl (file system ACL control) to enable ACL support for each volume (filesystem) that you want to use ACLs on. The fsaclctl utility operates on a single volume using the p path option or on all mounted volumes using the a option. With no other options, fsaclctl displays the state of ACL support on a volume. You must be working as root or use sudo to enable and disable ACLs. The e option to fsaclctl enables ACLs on the specified volume(s), and the d option disables them: # fsaclctl -p / Access control lists are not supported or currently disabled on /. # fsaclctl -p / -e # fsaclctl -p / Access control lists are supported on /. Caution: Enabling ACLs may cause errors Enabling ACLs on a filesystem prevents some programs that handle extended attributes (page 93) from working correctly. If a file has a resource fork but no ACL, attempts to copy it may fail with an error message such as the following: $ pax -w -f arch.pax picture.jpg pax: Unable to open ._picture.jpg to read <No such file or directory> Some utilities, such as cp, are not affected by this problem. How ACLs WorkEach access rule in an ACL specifies a user or group, the word allow or deny, and one or more actions such as read, write, and execute. When a user attempts to access a file, OS X tests in turn each rule in that file's ACL. If it finds a match for the user attempting to access the file and for the action that the user is attempting to perform on the file, the allow or deny word in that rule determines whether the user can access the file. If no match is found, the next rule is tested. If no rules match, OS X uses the traditional UNIX file permissions. Because ACL rules are applied before traditional UNIX permissions, ACL rules override traditional UNIX permissions. Caution: cp does not copy ACLs Regardless of which options you specify, cp does not copy ACLs. The Finder does not copy ACLs either. However, the tar utility (page 862) copies and restores ACLs. Creating ACL RulesIn the following example, Sam uses ls l to display permissions for the report file. You can tell that this file has no ACL because no plus sign (+) appears to the right of the permissions: $ ls l report -rw-r--r-- 1 sam sam 0 Jun 26 14:52 report chmod An extension to chmod allows you to add, remove, and modify ACL rules for a file. Sam uses chmod to add (+a) an access control rule so that Zach can read from and write to report. Refer to "ACLs" on page 678 for more information on using chmod to control ACLs. The output of ls l now shows a plus sign following the permissions, indicating that the file has an ACL. The e option to ls, when used with l, displays a file's ACL. $ chmod +a "zach allow read,write" report $ ls -l report -rw-r--r-- + 1 sam sam 0 Jun 26 14:52 report $ ls -le report -rw-r--r-- + 1 sam sam 0 Jun 26 14:52 report 0: user:zach allow read,write Mac OS X controls access to files based on ACLs. As with other extended attributes, some utilities and programs may not copy or preserve ACLs when working with a file. See page 678 for more information on ACLs. |
![A Practical Guide to UNIX[r] for Mac OS[r] X Users](/icons/5563-small.jpg "A Practical Guide to UNIX[r] for Mac OS[r] X Users"){kind=icon}
EAN: 2147483647
Pages: 234