locked files on HFS+ home partition shared between OSX/Linux

Question

I dual boot into Arch Linux and OS X 10.6 on my MacBook pro. I synced my UID between both OSes and created an HFS partition (with no journaling) to use as a shared home/Users partition. For the most part it works just as I'd expect, but sometimes when I'm booted into OS X certain files are "locked" (when I get info on a particular file the "Locked" box is checked under the "General" pane. I can resolve the issue by manually unchecking the box) and/or I get "Operation not permitted" when I try deleting or chmod'ing a file. In both cases I don't see anything out of the ordinary on the permission bits displayed with ls -l, except for a trailing '@' character in the position where the sticky bit would normally occur:

-rw-r--r--@  1 myuser  mygroup   296 Mar 29 11:44 myfile

This '@' character shows up on ALL normal files, so doesn't seem to be linked to the locked/operation not permission situation.

On the Linux side of things I never have permission problems. To the best of my limited knowledge and experience with ACLs I've not found any ACLs on any of the files in question.

For what it's worth, I do most of my file editing using emacs (Aquamacs in OSX), is it possible it is setting weird permission bits?

1. What is the "locked" setting that OS X uses and does it have a permission bit equivalent (so at the very least I could recursively unlock all files in my home directory from the terminal)
2. why might some, but not other files get "locked" when booting into OS X
3. what is the meaning of the '@' character?

Answer 1

The @ means that file has "extended attributes" (extra metadata, abbreviated "xattrs") attached to it in the filesystem. To see the list of xattrs attached to the files, do ls -l@ in Mac OS X.

Classic Mac OS had the concept of "Finder Info" which was a small fixed (non-extensible) set of metadata that all files on an HFS volume had. This included the "type and creator codes", and the "Finder flags", including the "locked" bit, the "visible" (hidden) bit, and several others. Mac OS X has basically deprecated the old Finder meta-data, but on the occasions where it's still needed, it now gets attached to the file's record in the filesystem as an xattr. Those locked files you're seeing almost certainly have this Finder info xattr attached, so that the state of the old Finder "locked" bit can be recorded.

My Snow Leopard system has a /usr/bin/xattr command that seems to have no man page, but it does have a usage statement if you invoke it with -h. Note that xattr -l filename can be useful to get a hex/ASCII dump of the values of the xattrs attached to a file.

Mac OS X's built-in commands for viewing and manipulating the old Finder info xattr from the terminal include GetFileInfo(1) and SetFile(1).

Update:
I have no good explanation for why those files are getting locked, but my hunch would be that whatever HFS support software you're running in Linux is either misunderstanding the purpose, and the deprecated status, of the old Finder lock bit and setting it when it shouldn't, or it's intentionally using the lock bit as a mechanism to map some kind of Linux filesystem semantic concept onto HFS.

The Finder lock bit was intended as a way for users to manually lock their own files so they didn't accidentally modify or delete them, and was not meant as a mechanism for process-level file locking to avoid multiple processes writing to the same file at the same time. That is, it was not supposed to be a replacement for fcntl(2) or flock(2). At the time the Finder lock bit was designed, the Mac was not a multiprocessing system.

Update 2: It could also be that Aquamacs is abusing the old Finder lock bit to carry out emacs' file locking wishes.