2.2. Resource Forks and HFS Metadata

2.2. Resource Forks and HFS+ Metadata

Apple's HFS+ filesystem has been stashing metadata away since its introduction in Mac OS X 8.1. Resource forks are generally invisible portions of files used for stashing additional information (the primary portion of the file indeed the only part of a file most Unix Geeks are used to thinking about is called the data fork ). Before Mac OS X, resource forks contained application resources. These are now contained in the application bundle itself, although resource forks are still used in classic applications and a few odd places (such as text clippings, which you can create by dragging and dropping text selections to the Finder).

You can inspect a resource fork by appending /rsrc to a file name, as in:

     $ ls -l Sample.textClipping     -rw-r--r--   1 bjepson  bjepson  0 Feb 27 11:05 Sample.textClipping     $ ls -l Sample.textClipping/rsrc     -rw-r--r--   1 bjepson  bjepson  1770 Feb 27 11:05 Sample.textClipping/rsrc 

The contents of a resource fork, even for something simple like a text clipping, are not necessarily human-readable, but there's usually something you can dig out:

     $ file Sample.textClipping/rsrc     Sample.textClipping/rsrc: ms-windows icon resource     $ strings Sample.textClipping/rsrc     KApple's HFS+ filesystem has been stashing metadata away since its     introduction in Mac OS X 8.1. Resource forks are generally invisible     portionsof files used for stashing additional information (the primary     portion of the... 

Mac OS X Tiger also makes use of HFS+ metadata, which consists of extended attributes that are associated with files. For example, if you look at the root of your Mac's hard drive in the Finder, you'll only see a small subset of the files (at the very least, Library, System, Applications, Users). But if you drop down into the Terminal, there are plenty more. The files that don't appear have an attribute (I) that makes them invisible to the Finder.

You can inspect this metadata with GetFileInfo and set it with SetFile, both of which are located in /Developer/Tools:

     $ GetFileInfo Sample.doc     file: "/Users/bjepson/Desktop/Sample.doc"     type: "W8BN"     creator: "MSWD"     attributes: avbstclinmedz     created: 02/27/2005 11:20:47     modified: 02/27/2005 11:21:01 

An uppercase attribute indicates that the attribute is toggled on, and lowercase means it is off. The SetFile manpage describes all these attributes. For example, to hide the file extension in the Finder, set the E (extension is hidden) attribute:

     $ SetFile -a E Sample.doc 

You can also change the creator code and file type with -c and -t, respectively. For example, to change Sample.doc so it's owned by NeoOffice/J (http://www.neooffice.org), set the creator code to the empty string and the file type to NO%F, as shown in the following listing and in Figure 2-3.

Figure 2-3. NeoOffice owns Sample.doc now

     $ SetFile -c "" -t "NO%F" Sample.doc     $ GetFileInfo Sample.doc     file: "/Users/bjepson/Desktop/Sample.doc"     type: "NO%F"     creator: ""     attributes: avbstclinmEdz     created: 02/27/2005 11:20:47     modified: 02/27/2005 11:21:01 

2.2.1. UFS

Although UFS doesn't natively support resource forks or HFS+ attributes, Mac OS X finds a place to stash that info. If the file has either a resource fork or any attributes that depend on HFS+ semantics, this information goes into a file named ._filename, where filename is the name of the original file (this is known as the Apple Double format ):

     $ touch Foo     $ ls -al     total 4     drwxr-xr-x   2 bjepson  bjepson  1024 Feb 21 20:54 .     drwxr-xr-x   6 bjepson  bjepson  1024 Feb 21 20:53 ..     -rw-r--r--   1 bjepson  bjepson     0 Feb 21 20:54 Foo     $ SetFile -a S Foo     $ ls -al     total 6     drwxr-xr-x   2 bjepson  bjepson  1024 Feb 21 20:54 .     drwxr-xr-x   6 bjepson  bjepson  1024 Feb 21 20:53 ..     -rw-r--r--   1 bjepson  bjepson    82 Feb 21 20:54 ._Foo     -rw-r--r--   1 bjepson  bjepson     0 Feb 21 20:54 Foo 

2.2.2. Preserving Metadata

Before Mac OS X Tiger, you had to be very careful with what you did at the command line. If you used cp, mv, rsync, or any of the other command line utilities that move stuff around, you could have lost part of your file. It was easy to miss this sort of mayhem, since this metadata isn't apparent until you go looking for it, and it wasn't always a disaster. For example, you could have copied a graphics file that kept its preview in its resource fork, and you probably wouldn't have missed it after all, the next time you opened the image, the application most likely regenerated the preview. But with other files, such as text clippings and Internet locations (drag a URL from Safari to the Finder to create one of these), you lost everything, since all of these files' contents are contained in the resource fork. Here's how it would go on Mac OS X 10.3 and earlier:

     $ ls -l Resource\ Fork\ Example.webloc     -rw-r--r--   1 bjepson  bjepson  0 Feb 21 15:54 Resource Fork Example.webloc     $ ls -l Resource\ Fork\ Example.webloc/rsrc     -rw-r--r--   1 bjepson  bjepson  624 Feb 21 15:54 Resource Fork Example.webloc/ rsrc     $ cp Resource\ Fork\ Example.webloc foo.webloc     $ ls -l foo.webloc     -rw-r--r--   1 bjepson  bjepson  0 Feb 26 23:18 foo.webloc     $ ls -l foo.webloc/rsrc     -rw-r--r--   1 bjepson  bjepson  0 Feb 26 23:18 foo.webloc/rsrc 

It's not just the resource fork that got clobbered, you also lost the HFS+ metadata:

      [Before...]     $ GetFileInfo Resource\ Fork\ Example.webloc      file: "/Users/bjepson/Desktop/Resource Fork Example.webloc"     type: "ilht"     creator: "MACS"     attributes: avbstclinmEdz     created: 02/26/2005 23:18:33     modified: 02/26/2005 23:18:33      [After...]     $ GetFileInfo foo.webloc      file: "/Users/bjepson/Desktop/foo.webloc"     type: ""     creator: ""     attributes: avbstclinmedz     created: 02/26/2005 23:18:52     modified: 02/26/2005 23:18:52 

Fortunately, Mac OS X Tiger finally makes this problem (mostly) go away by making all the cp, mv, and rsync command-line utilities aware of the resource forks and HFS+:

     $ cp Resource\ Fork\ Example.webloc foo.webloc     $ ls -l foo.webloc/rsrc     -rw-r--r--   1 bjepson  bjepson  717 Feb 26 23:25 foo.webloc/rsrc     $ GetFileInfo foo.webloc     file: "/Users/bjepson/Desktop/foo.webloc"     type: "ilht"     creator: "MACS"     attributes: avbstclinmEdz     created: 02/26/2005 23:25:21     modified: 02/26/2005 23:27:15 

If you copy or move the file to a non-Mac system such as a FAT-formatted memory card, Apple Double comes in to save the day:

     $ cp Resource\ Fork\ Example.webloc /Volumes/NO\ NAME/     $ ls -al /Volumes/NO\ NAME/ | grep Res     -rwxrwxrwx   1 bjepson  bjepson   4434 Feb 27 09:45 ._Resource Fork Example.webloc     -rwxrwxrwx   1 bjepson  bjepson      0 Feb 27 09:45 Resource Fork Example.webloc 

And if you rm a file on a volume that's using Apple Double (including UFS as well), it cleans up the ._ file:

     $ rm /Volumes/NO\ NAME/Resource\ Fork\ Example.webloc     remove /Volumes/NO NAME/Resource Fork Example.webloc? y     $ ls -al /Volumes/NO\ NAME/ | grep Res     [... no results ...] 

For the most part, Mac OS X has you covered when it comes to preserving resource forks. There are a few gotchas that you need to watch out for: sftp, ftp, and scp won't create the resource fork for you.

Also, some tools, such as the Unison File Synchronizer (http://www.cis.upenn.edu/~bcpierce/unison/), will try to create the resource forks on the Unix, Linux, or Windows end of the transaction. While this sort of thing works smoothly for the most part, it can occasionally trip you up. We'll talk about those issues and many others in the next chapter.