I mentioned previously of the joys that I hadn't had with AFP and home directories. I've still got some of those problems, but not as bad as before, thanks to some more digging around that I've managed to do.

Firstly, the errors that I was getting with regards to permissions is actually a Microsoft problem, rather than an AFP problem. It seems that when Microsoft Word on the Mac saves a file that's hosted on a network share, it tries to write a temporary copy first, then move that copy to the new location. At least that way, if there's any (more) problems with Microsoft Word, it doesn't affect the older copy.

It turns out that this problem is known, and it's to do with the shitty way that it handles temporary files. When Word wants to write a temporary copy, it's got to do it on the same device, so that when the 'move' operation occurs, it's (almost) atomic. So instead of writing a copy to the local device, it needs to write a temporary copy to the server.

Now, if you've already got your home drive mounted on the server, you'd think it would know that, wouldn't you? Pretty much anywhere would be good. But it doesn't take that approach -- or even use the ~/Library/TemporaryItems folder -- it tries to write it directly to the share itself. That's right, it tries to write it to afp://server/share/.TemporaryItems. Obviously. Should have guessed. Completely transparent from the "Permissions error" message that it puts up.

So, first I made afp://server/share/.TemporaryItems a soft link to /tmp. At least that way, temporary files are created where they're supposed to live; and in any case, each user gets their own subfolder anyway. That worked; anyone could then write to files in .TemporaryItems and I thought the problem was solved. Nope, still getting a permissions error (exactly the same error, mind you, and no different messages or indicators that were there last time).

It turns out that it needs .TemporaryItems to be on the same share as the file it's copying to. That way, when it does the mv, it's just a directory entry update. (Seems sensible, in a round-about way.) So I made a (shudder) global writable .TemporaryItems folder that anyone can dump stuff into (hey! free place to store porn...) and since it's a dot folder, it doesn't show up in Finder.

It *then* turned out that sometimes, Microsoft Word uses the ~/Library/TemporaryItems folder too. So that needs to be on the same share in order to work.

I wonder whether some of this cruft is around from pre-Mac OS X days, where there were crappy workarounds for dealing with writing files. But in this day and age, when a piece of software demands a globally writable share in order to achieve a basic function, it's time to switch over. Fortunately, Text.app is a reasonable replacement for looking at Microsoft files; but you wouldn't want to use it as a primary means for writing if you're exchanging important documents with clients. Let's just hope that Open Office starts to become more of a better Mac citizen. The 1.x builds weren't (they were just using the X11.app to draw on the screen) but I hear that the 2.x builds will be native Cocoa applications.

(Oh, for those of you on the Mac scene, the Mac Business Unit at Microsoft have started a Mac Mojo blog, written by people there. Vaguely uninteresting so far. However, you can take a Tour of the MBU, which is actually quite fun :-)

Anyway, it seems that my vented frustration at the Mac should be more properly aimed at Microsoft; AFP is just the middleman in this circumstance. (I'd probably have exactly the same problem if it were an NFS drive; except that I suspect Word would do something different in that case.) I also found out (see my whinging on the earlier Mac post) that the reason that the permissions were being buggered on the Group share was because it was being shared as a Group, and as such, it was giving people who connected to it access via the 'group' membership rather tha the 'user' membership. God knows why it wants to do that though.

Of course, we've also had WWDC since, and there were rumblngs about having better support for network mounted shares. (They claimed that before though, with the Home drive sync for laptops. That was crap though; you either have a 'mobile' account or a 'non-mobile' account. Hey, guess what -- I don't have a mobile account; I have a 'mobile' computer and a 'non-mobile' computer. WTF would I want to copy all my stuff across the net onto my 'non-mobile' computer when I can just access it via a network share? You only need that for the 'mobile' computer. Plus, the home sync doesn't sync your ~/Library directory (you know, where all your important stuff is stored like preferences, address books etc.). I guess that they were just trying to sell more .Mac subscriptions to sync all that stuff over. Mind you, you probably wouldn't want to copy ~/Library/Caches to your network home -- but then I have that as a link to space on a local drive anyway.)

One of the things that may help is moving from Automount to AutoFS. There's a real possibility that they're going to get the network shares mounted properly this time, but I'll believe it when I see it. It's also a shame that it's not going to come with any beefier operating system -- NFS4 would have been nice, but something like AFS (that transparently clusters all available hard drives) would have been even better. I guess that cuts into their XSan sales, though, or even the Xserve Raids.

Ah well, with a sledgehammer, I managed to crack the bug. It's given AFP a lease of life; possibly until Tiger comes out. But I haven't written off a switch back to NFS yet ...