Ensuring group ownership of new files on AFP server

After a recent transfer of our server, ownership (and thus access) of newly created files was being assigned to the creator. Old files could still be accessed by members of the group. It seems the solution to this was to use Workgroup Administrator to change the AFP sharepoint so that it used “Inherit permissions from parent” rather than the “Standard POSIX behaviour” (which in standard UNIX style is probably more secure but less useful 🙂
Fortunately this seemed to work so I didn’t have to enable and implement appropriate ACL’s 🙂

Why you don’t want to run ZFS on your Mac

Fabulous article in MacJournals Mac Weekly Journal about ZFS (it’s worth the subscription), and why it won’t be the default Mac filesystem. Namely

  • Even Sun don’t have it bootable yet
  • CPU load for scrubbing the filesystem isn’t going to appeal to users who already complain about Spotlight indexing
  • It chews up much more disk space.
  • FATZAP object headers chew up 128K each. Theres one of these for every chunk of metadata that doesn’t fit in a microzap block. Think resource forks, even if they’re empty. With 600,000 files or so it’s likely to chew up around 15Gb of space.
  • Metadata attributes can only have up to 50 character names
  • It’s case sensitive
  • You currently can’t remove drives from a ZFS storage pool
  • ZFS filenames are 255 bytes. HFS Plus supports up to 255 UTF-16 characters

Of course if you happen to have a server with tons of storage, it might be appropriate as it does some very cool things such as guaranteeing data integrity, snapshots (which chew up disk space as they preserve all the blocks from the time the snapshot is taken).
Meanwhile Apple has now stated that ZFS will only be available as a read-only option from the commandline.