However, you need to be careful with redirects. Redirections will revert to using the GET method which usually isn’t what you want, so you need something like:

- (NSURLRequest *)connection:(NSURLConnection *)connection
             willSendRequest:(NSURLRequest *)request
            redirectResponse:(NSURLResponse *)redirectResponse
{
    if ([[request HTTPMethod] isEqualTo:@"HEAD"])
        return request;

    NSMutableURLRequest *newRequest = [request mutableCopy];
    [newRequest setHTTPMethod:@"HEAD"];

    return [newRequest autorelease];
}

I suspect that this bug report is invalid: http://openradar.appspot.com/7019347.

Now wherever you see objc_msgSend (or something similar), the selector gets passed in $rsi. To find out what it is, type:

p (char *)sel_getName($rsi)

x86_64 comes with instruction pointer relative addressing so you might notice that gdb helpfully displays what the target address is wherever it’s used. So if you’re looking at some assembler that looks like this:

0x00007fff811f33fc <-[NSTableView reloadData]+115>: mov -0x10f16b8b(%rip),%rsi # 0x7fff702dc878
0x00007fff811f3403 <-[NSTableView reloadData]+122>: mov %rbx,%rdi
0x00007fff811f3406 <-[NSTableView reloadData]+125>: callq 0x7fff8184278e <dyld_stub_objc_msgSend>


You can figure out what the call is by typing:

p (char *)sel_getName(*(void **)0x7fff702dc878)

And you’ll see something like:

$2 = 0x7fff8187bb68 "_endMyEditing"

*** attempt to pop an unknown autorelease pool (0x12345678)

You can debug it by setting a breakpoint in the _CFAutoreleasePoolPop function. To find out exactly where, disassemble the _CFAutoreleasePoolPop function, and look for the first call to CFLog. On the i386 architecture it’s at _CFAutoreleasePoolPop+84.

char *_Block_dump (block_t block);

It’s not in any public header so you’ll have to declare it yourself. It returns a debug string you can log and will give you the retain count of the block, whether it’s a global, stack or heap block and other information.

Firstly, I reasoned that Launch Services would probably have a private API that Finder uses to set it. I could have gone through all the symbols that Launch Services exports, including the private ones looking for likely candidates. To do that, you use the nm tool:

nm /System/Library/Frameworks/CoreServices.framework/ \
Versions/A/Frameworks/LaunchServices.framework/LaunchServices

That will spew out a load of information. Any symbols that are tagged U, are undefined which mean they're come from somewhere else--another framework or library. We're interested in symbols that are tagged T since they're symbols that are exported by that framework. Symbols that have a lower case t, are local to the module and aren't exported. Binaries that are stripped shouldn't have any symbols with a lower case codes. Remember that all C symbols will have an underscore at the beginning that you won't see in your code. C++ symbols are a different story that I won't go into here.

OK, so that's one way I could have figured it, but I got bored looking through them all, so...

Since I knew that Finder was able to set the binding, I figured I could just see what Finder does, but how to do that? What I did was attach the debugger (gdb) to Finder and set some breakpoints. To attach the debugger to Finder:

gdb /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
attach Finder<TAB>

Apple's version of gdb supports tab completion for the attach command so when you press the tab command you should find it fills in the process id of Finder.

Now what to set the breakpoints on? Well, I first tried setting the breakpoint on write--obviously setting the binding is going to involve writing to the disk at some point (I already knew that the binding was set as part of the usro resource in the resource fork) so my idea was that I'd set a breakpoint on write and then set a binding in Finder and see what we got. There aren't actually that many primitives for writing to the disk; all the Cocoa and Carbon frameworks eventually call BSD primitives to do what they want so you usually just need to set breakpoints on write/pwrite. For example, you'll probably find -[NSData writeToFile:atomically:] calls a CoreFoundation function which then calls one of the BSD write functions.

To set a breakpoint:

b write

Now on my system it sets breakpoints in two places, on write and write$NOCANCEL. That's fine so I just continued. Type c to continue.

OK, those of you playing along at home will find that whilst it might stop in a few places whilst you're trying to set the binding (e.g. when an open panel appears), it doesn't stop after you've actually set the binding. By the way, to continue after hitting a breakpoint, type c.

So then I set a breakpoint on pwrite, and this time, just after setting the binding, the debugger stops. What now? Well, we want a backtrace. To get that, type bt and this is what we get:

#0 0x00007fff82b8b03c in pwrite ()
#1 0x00007fff821b6b1a in BasicWrite ()
#2 0x00007fff821b6a49 in PBWriteForkSync ()
#3 0x00007fff821b69d6 in FSWriteFork ()
#4 0x00007fff822281c0 in WriteData ()
#5 0x00007fff822282d3 in WrResource ()
#6 0x00007fff821ca33a in UpdateTheFile ()
#7 0x00007fff821ca035 in UpdateResFileCommon ()
#8 0x00007fff8213a028 in _LSSetStrongBindingForRef ()


It goes on but I stopped at _LSSetStrongBindingForRef. As you can see, there are a bunch of Carbon functions before we get to the pwrite call.

To get the prototype for the function I searched Google and found someone had already done it for me. ;-)

I should note that you'll probably want to detach from Finder: type detach, and then Finder will continue running. If you don't, you'll probably end up killing Finder which isn't actually such a big deal as it'll just be restarted for you.

Anyway, every programmer should get seriously familiar with gdb. In this case, I've used it to discover a private API which I personally wouldn't use and don't recommend others using either, but I have used similar techniques before to debug problems I've had with some of Apple's frameworks, not to mention my own code. I've mentioned the nm command which is useful, but there's also otool which will dump things like what libraries a binary is linked to; there's the awesome class-dump tool; there's fs_usage for monitoring what accesses the disk and lsof for tracking down open files, and then there's dtrace and probably many more that I've forgotten.

They’re not.

Uniform Type Identifiers are just a type. To be able to work out the type of something you have to look at some metadata which for the vast majority of things isn’t a UTI. For most files on your Mac, it will be the extension of the file that determines what type of file it is. About the only place that you’ll see a UTI is within the property list of an application where it says what types it supports.

As far as I know, there is no direct replacement for creator codes. There is no other metadata that you can put on the file that tells the system what application created it, and even if there was, UTIs would have little to do with it since UTIs represent types, not applications.

There is metadata on a file that is used to say what application should open the file (on a per file basis). This is stored within the resource fork of the file in a usro resource. This simply stores the path of the application (no UTI is involved) that should open a file and yes, this could be used to replace creator codes—I don’t know if there’s an API for setting them, I haven’t checked. Launch Services has a private API that you could use to set the binding:

extern OSStatus _LSSetStrongBindingForRef(const FSRef *inItemRef,
                                          FSRef *inAppRefOrNil);

I don’t know why Apple have got rid of creator codes but it is a shame they haven’t replaced them with something. Perhaps they haven’t had time to figure out what to replace them with. Thinking about it, what you probably want is to store the bundle ID of the application that created the file in some metadata somewhere (as an extended attribute or within the resource fork). I haven’t thought it through, but there might also be security issues with creator codes—malicious programs could set them behind your back and cause bad stuff to happen.

(It’s broken because ibtool runs as a 64-bit app. and can’t load AppleGlot’s plugin which is 32-bit).

hexdump -e "8/1 \"0x%02x, \" \"\n\"" <file>

(This post is for my benefit as much as anyone else.)

sudo nvram boot-args=msgbuf=65536

level = kIOStorageAccessNone;
while ( ( object = objects->getNextObject( ) ) )
{
    if ( object != client )
    {
        level += _openClients->getObject( ( OSSymbol * ) object );
    }
}

Basically, it’s going through a list of clients that it services and works out what the aggregate access level is for all the clients. Here are the possible access levels:

enum
{
    kIOStorageAccessNone          = 0x00,
    kIOStorageAccessReader        = 0x01,
    kIOStorageAccessReaderWriter  = 0x03,
    kIOStorageAccessSharedLock    = 0x04,
    kIOStorageAccessExclusiveLock = 0x08
};

Now, from looking at this code, it looks wrong because of the use of the +=. Surely |= is more appropriate. It’s obvious to me now, but it took me some time before I found the bit where they’d overridden the += operator:

inline void operator+=( IOStorageAccess access )
{
    _access = ( ( _access - 1 ) >> 1 ) & 7;
    _access = gIOMediaAccessTable[ ( ( access - 1 ) >> 1 ) & 7 ][ _access ];
    _access = ( ( _access & 7 ) << 1 ) + 1;
}

Anyway, this, in my opinion, is a classic example of an abuse of C++ operator overloading. The rule when writing code should be to make it as readable and as obvious as possible first before you start trying to be clever. If the code had been something like this:

    clientLevel = _openClients->getObject( ( OSSymbol * ) object )->unsigned32BitValue( );
    level = aggregateLevel( level, clientLevel );

it wouldn’t have cost me any time as it would have been clear what was going on.

It’s for similar reasons that I always put brackets round expressions that combine && and || clauses: not everybody knows the order of precedence of these two and it’s easy to forget; adding brackets means you don’t need to remember.

For example, I would always do:

    if ((a && b) || (c && d))

rather than

    if (a && b || c && d)

I know it’s tempting to use that clever bit of the language that you just learnt about but in doing so you might make it harder for the person that follows you. The general rule should be: unless it is a common idiom, make it clear what’s going on and if a better known alternative exists, use that instead.

Using Disk Arbitration, you can send requests to eject disks, mount and unmount volumes, rename volumes and you can claim a disk for exclusive use. For each of those operations you can also approve or reject requests that other applications make. It’s not actually enforced: you could still force a volume to be unmounted and claiming a disk for exclusive use doesn’t stop anyone else from using it (like advisory file locks). You can see some of these notifications flying around by using disktool with the undocumented -y flag. You can get more debug by hacking the com.apple.diskarbitration.plist file in /System/Library/LaunchDaemons and adding the -d flag to the argument list. You’ll then get /var/log/diskarbitrationd.log.

diskarbitrationd is the main daemon that’s responsible for all this stuff. The source code for it and related things can be found on the Open Source part of Apple’s site. To use Disk Arbitration from within your application, you need to link to the Disk Arbitration framework. It was a private framework in Panther (10.3) but was made public in Tiger (10.4). Things like Spotlight use it to know when to stop indexing a volume when you want to unmount a volume and you should use it too if you’re writing a similar application.

There are a couple of files that it looks at to tell it what to do. /etc/fstab is one of them. The shipped version (in Leopard) has some examples in the comments of /etc/fstab and the man page looks pretty good. By making the appropriate change to this file, you can, amongst other things, stop a volume from being automatically mounted. The other file it looks at is /var/db/volinfo.database. This text file stores the setting of the “Ignore ownership of this volume” flag that you see in Finder.

Disk Arbitration will also give you information about all the disks and volumes on the system. Here’s the kind of information it might have about your startup volume:

{
    DAAppearanceTime = 244372661.099552;
    DABusName = PMP;
    DABusPath = "IODeviceTree:/PCI0@0/SATA@1F,2/PRT2@2/PMP@0";
    DADeviceInternal = 1;
    DADeviceModel = "WDC WD1600JS-40NGB2                     ";
    DADevicePath = "IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/SATA@1F,2/AppleAHCI/PRT2@2/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice";
    DADeviceProtocol = SATA;
    DADeviceRevision = "10.02E04";
    DADeviceUnit = 0;
    DAMediaBSDMajor = 14;
    DAMediaBSDMinor = 3;
    DAMediaBSDName = disk0s3;
    DAMediaBSDUnit = 0;
    DAMediaBlockSize = 512;
    DAMediaContent = "48465300-0000-11AA-AA11-00306543ECAC";
    DAMediaEjectable = 0;
    DAMediaIcon =     {
        CFBundleIdentifier = "com.apple.iokit.IOStorageFamily";
        IOBundleResourceFile = "Internal.icns";
    };
    DAMediaKind = IOMedia;
    DAMediaLeaf = 1;
    DAMediaName = "Macintosh HD";
    DAMediaPath = "IODeviceTree:/PCI0@0/SATA@1F,2/PRT2@2/PMP@0/@0:3";
    DAMediaRemovable = 0;
    DAMediaSize = 138155196416;
    DAMediaUUID = <NSCFType: 0xd32f150>;
    DAMediaWhole = 0;
    DAMediaWritable = 1;
    DAVolumeKind = hfs;
    DAVolumeMountable = 1;
    DAVolumeName = "Macintosh HD";
    DAVolumeNetwork = 0;
    DAVolumePath = file://localhost/;
    DAVolumeUUID = <NSCFType: 0xd3316b0>;
}

That’s obviously for a specific partition on a disk. There’s another entry that represents the whole disk.

Something to note regarding disk/volume UUIDs: GUID partition schemes have a UUID that is used for the partition but in addition to that, there is a UUID that is stored as part of the file system (in the case of HFS+, it’s not actually a UUID but eight bytes that get turned into a UUID), so if you do end up using them, make sure you know which one you’re dealing with. The UUID reported by Disk Arbitration happens to be the file system UUID but the UUID property of IOMedia objects is from the partition table.

One thing that isn’t ideal is there’s no actual notification indicating when the system wants to eject a disk. You can use the eject approval notification, but then there’s no way to find out if the eject was ultimately approved. This would be a problem for, say, an indexing application, where it might want to release all resources for the disk (so that the eject will actually succeed) when an eject is requested. Spotlight probably uses the eject approval callback, but the only way it would be able to restart indexing on a volume that failed to eject, is by checking again after a certain amount of time (I don’t know if it does that).

Another problem I found recently is that bad clients can cause it to eat memory and this in turn can cause kernel memory leaks (of IOMedia objects). For example, on the currently shipping version of Leopard, the WindowServer process doesn’t appear to be properly processing Disk Arbitration notifications (probably because it uses a funny run loop) which is ultimately causing IOMedia objects to hang around in the kernel. It’s not a big deal but it does need fixing.

Oh, and one other thing, the system does not like it if Disk Arbitration crashes. Even though launchd will restart it, you still need to reboot as Finder and other processes don’t connect to the new version.

I was curious to know what difference it would make for a simple FIFO queue so I knocked up a mostly lock free based implementation and a conventional lock based version. I chose to make things slightly harder by choosing a fixed size queue and having it block when the queue was full.

The lock free version was nearly thirty times faster on the machine I tested it on. Disclaimer: I did this pretty quickly and I wouldn’t be surprised if there are bugs (I haven’t tested it on a multiprocessor weakly ordered architecture machine).

Here’s the code.

Update: I thought I might explain how I figured out it was the /etc/authorization file was corrupt since you could use the same techniques to debug other start up issues.

The first thing I did was to boot up from another drive and run Disk Utility: no problems. Then I had a look at the system.log file in /var/log/. It showed a bunch of errors but the first one indicated that securityd had crashed. The crash log (stored in /Library/Logs/CrashReporter/) showed a crash in CFDictionaryContainsKey which got me thinking it was a problem with a property list file somewhere. To figure out which property list file, I booted the system in single user mode (Command-S) and typed:

    mount -uw /
    fs_usage >/var/log/fs-usage &

and then:

    exit

to continue booting. After rebooting into a working system, I was able to examine the /var/log/fs-usage file. I looked for the last thing that securityd did before it crashed and that was to read /etc/authorization and sure enough the file was garbage when I looked at it.