I heard during the betas that cp/mv supported resource forks now. I tested it then and they worked great. Handy, I thought, and moved on. Then I heard that rsync supported those as well as extended attributes now. Very handy, I thought, and moved on. Now that it’s out I decided to take a closer look and found some curious things.
First, I made a test.
$ mkdir test
$ cd test
$ mkdir dir1
$ mkdir dir2
$ echo “data” > dir1/file
$ echo “rsrc” > dir1/file/rsrc
$ xattr —set somekey somevalue dir1/file
$ xattr —list dir1/file
dir1/file
com.apple.ResourceFork rsrc
somekey somevalue
$ cp dir1/file dir2/
$ xattr —list dir2/file
dir2/file
com.apple.ResourceFork rsrc
somekey somevalue
And, thus, it appears that the Unixification of the resource fork is complete. It’s now an extended attribute (xattr) of a file with the key “com.apple.ResourceFork” and any program that handles those attributes will copy the resource fork now. Spotlight stores its data in a BDB in /.Spotlight-V100 and not in xattr records, so that doesn’t get copied as a part of xattr support.
Now, also, rsync has a new flag -E to handle these xattr attributes. Appears to work the same way. As with all rsync options, if the remote end does not handle it, the it won’t get transmitted, and thus stored, on the other end. Make sure you rsync to a Tiger Mac or some other system that handles these files.
$ rm dir2/file
$ /usr/bin/rsync -avE dir1/ dir2/
building file list … done
./
.DS_Store
._.DS_Store
file
._file
sent 6722 bytes received 100 bytes 13644.00 bytes/sec
total size is 6153 speedup is 0.90
$ xattr —list dir2/file
dir2/file
com.apple.ResourceFork rsrc
somekey somevalue
In limited testing, it appears that while rsync tries to send the resource fork data, it never makes it across.
$ rsync -avzE dir1/ user@tiger.local:.
building file list … done
file has vanished: “/Users/user/test/dir1/._file”
sent 101 bytes received 40 bytes 94.00 bytes/sec
total size is 5 speedup is 0.04
rsync warning: some files vanished before they could be transferred (code 24) at /SourceCache/rsync/rsync-20/rsync/main.c(717)
First off, I think it might be nice to mention that xattr isn't a utility bundled with OS X. IIRC, it's from the Ars Technica Tiger review, yes?
Second, I'd be surprised if the resource fork was stored as extensible attributes on the file, for several reasons:
The filesystem already supports a resource fork, so why use extensible attributes?
Extensible attributes have a size limit, so any reasonable-length resource fork wouldn't fit.
I think it's more likely that the extensible attributes store the name of the resource fork. I don't know why that would be, but it's a possibility given the quoted example. Unfortunately I don't have xattr on this computer, so I can't test, but I may check later.
Ok, I was wrong, it is storing the resource fork in com.apple.ResourceFork. But that’s puzzling, since the extended attribute stores a limited attribute size, but AFAIK a resource fork isn’t limited like that.
Perhaps xattr is just displaying the resource fork without it actually being stored as an extended attribute? Or perhaps, god knows why, the resource fork is being stored as an extended attribute if it can fit in that size?
Anybody know more?
Ok, I'm suggesting that xattr is simply listing the resource fork of the file.
I just created a file that was 2MB in length (yes > foo) and copied it to the resource fork of a file (cp foo bar/rsrc). I then listed it (xattr -l bar) and it displayed the whole thing in com.apple.ResourceFork. And yet, extended attributes are limited to 4k in size. So this leads me to believe that it's simply displaying the resource fork, for some unknown reason.
There’s no hard limit on attribute sizes. The 4K limit is only a recommendation.
As for the resource fork, my guess is that, like type and creator codes, they can be accessed via extended attributes but the actual data is still stored in the same old place(s). In other words, the EAs for these items are merely proxies. But that’s just a guess…
There’s a lot of talk in development circles about old disk utilities horking up Tiger drives and attributes and such. Until the dev docs on the disk format are updated it’ll be up in the air, but it’s possible they moved it in HFSX disks and have a holdover for older files.
—
cp