|
OS X supports the usual Unix file metadata, including the directory flag, file permissions (owner, group and others), creation date, etc.. But the OS X file system includes support for much additional metadata.
Users have easy access to some of this metadata via the Finder. If you select a file and then click on the "More info" button (if you are using Column view) or hit Cmd-I, the file's Info window will open, displaying a variety of metadata. You'll see creation and modification dates, and you can access Unix file permissions in the "Ownership & Permissions" part of the window (you can also read and alter these at a shell prompt as usual, with "ls -l" and "chmod"). You will also find various non-Unix metadata, known as extended attributes. These include a "Comments" field where you can enter plain text comments (these get examined when you use the Spotlight search tool), and specification of the default application for opening the document when it is opened in the finder. Some file types display other metadata as well.
There is metadata besides what you see in the Info window, however. You can view much of it via the command line with the mdls command. In fact, OS X file metadata is arbitrarily extensible, a feat made possible because the OS X file system supports forked files. A single OS X file-system file is actually potentially two files on its host volume: the data fork holding the data comprising the file's main content, and the resource fork holding metadata for the file. Unix commands typically access only the data fork.
Classic Mac OS relied heavily on resource forks. For example, applications would store the text for their menus and controls in the application resource fork. This simplified localization or customization of an application; the language used for menu items and buttons could be changed without having to recompile the application, simply by editing the resource fork contents. Applications could also store file-specific settings in the resource forks of documents, including such things as window size and position at the time of last use, or application-specific settings such as whether a text file should have Mac, Windows, or Unix line endings, or whether line numbers should be displayed during editing.
Most importantly, every Classic Mac OS file stored two fundamental resources in its resource fork, the file type and creator (encoded as 4-character strings). The type indicated, for example, whether the file was a plain text file, a rich text file (RTF), a Word file, an AIFF or WAV audio file, a Quicktime movie, etc.. The creator indicated the program the Finder should launch to open the file (e.g., Word for a Word or RTF file, Quicktime Player for a Quicktime movie, etc.). Apple maintained a database of registered type and creator IDs. Each application had a table of file types it was able to open. For backward compatibility, OS X has support for similar metadata, but the need for Unix compatibility makes such support complicated.
Mac OS X metadata presents two challenges for Unix command line users. First, important metadata must be preserved when using Unix commands to manipulate the file-system. The Unix implementation in Darwin mostly knows about OS X metadata, so basic commands like "mv" and "cp" preserve metadata (including resource forks). But more care must be taken when using command-line tools to archive files or to move OS X files back and forth between OS X file systems and other file systems. For example, "tar" does not archive file resource folks, "rsync" and "scp" do not copy resource forks unless given a special flag, and "sftp" only transfers data forks. This is particularly an issue if you use command-line tools for backups; more on this below.
The second challenge is in regard to file types and creators. Classic Mac OS use of type and creator resources made OS X support of legacy documents and applications a complex issue. The standard Unix file system has no formal support for file types and creators. Most typically, file suffixes indicate the file type merely by convention (e.g., ".txt" for text files, ".c" for C language source code files, ".mp3" for MPEG 2 layer 3 audio files, ".mpg" for MPEG movies, ".py" for Python scripts, etc.). Shell scripts might indicate a default program for running the script via the "pound-bang hack" ("#! /usr/bin/env ..."), but at the command line it is largely up to the user to figure out what program to associate with a given file. Window managers like GNOME can provide default application support for launching files from a file browser, but it is based on associating a file suffix globally with a single application. The default file creator cannot be altered for different files; you can't have one .jpg file open in XV by default, and another in the Gimp. Microsoft Windows operates similarly, with file suffixes tying files to applications.
OS X lives somewhat uncomfortably in both worlds. It has OS-level support for default applications associated with file suffixes, like Unix window managers. The Finder hides file suffixes from users by default (this can be altered), but they are there and play a role in identifying a file's default launcher (you can see them via a file's Info window). But OS X metadata can override the file suffix, allowing you to specify the default launch application for a file arbitrarily, regardless of its suffix. You can access this metadata via the Finder in two ways. If you Ctl-click on a file, the popup menu that appears offers an "Open with..." item. If you select it, you can choose the application with which to launch the file. If you hit the Option key before you select "Open with...", the menu item will change to "Always open with...". In this case, when you select an application, the file's metadata will be changed to reflect your choice of default application for the file. Alternatively, if you open a file's Info window, you'll find an "Open with" item allowing you to select its default application.
You can override the Finder's default choice of application associated with a file suffix as follows. Find any file with the suffix of interest, select it, and open its Info window. Choose the new default application. When you make your choice, click on the "Change all..." button in the same area of the Info window. This updates the Finder's suffix-application association table.
OS X metadata and its interoperability with Unix is a rich and complex topic. If you find you need to learn more about it, I recommend two documents:
•The challenge of integrating the Unix and Mac OS environments (a Usenix 2000 presentation by one of Apple's software engineers, Wilfredo Sánchez)
• Metadata, the Mac, and you
The bottom line is just to be aware that metadata is there; metadata issues may be the cause of subtle problems you come across. More often, they will just be a source of minor frustration if you work in a cross-platform environment. For example, if you use an OS X text editor to edit source code on your Mac, when you transfer the files to a Unix machine (say, via rsync to a flash drive or via sftp), work on them there and then transfer them back, their content will be as expected, but document-specific settings stored by the OS X application (such as window location and size) will be lost.
|
|
