I'm trying to detect disk mount/unmount notifications from a Foundation tool. Previous questions to this list (e.g. http://lists.apple.com/archives/cocoa-dev/2007/Jan/msg01170.html) on this topic have suggested the DiskArbitration framework, which I am using.
The DiskArbitration framework has a number of callbacks. However, none seems to do what I'm wanting to do. DiskAppeared callback: - Called when a volume is attached, even if not mounted. That is, if I have 2 partitions on an external drive but only 1 mounted, I will still hear about both. DiskDisappeared callback: - Called when a volume is physically gone, not just unmounted. If I unmount one volume on my external drive and leave the other mounted, I won't hear about the unmount through this callback. DiskDescriptionChanged callback: - I can register for changes on the DAVolumePath key, and this works if the volume is a physical external drive. If it's a network drive, though, then the description never *changes*; it begins life with the DAVolumePath key correctly populated. Between DiskAppeared, DiskDisappeared and DiskDescription I can usually be notified of all disk mount events, but I get some duplication, and in general it feels very hacked together. DiskMountApproval callback: - Notifies me that someone *wants* to mount the volume, but does not guarantee that the disk was actually mounted. DiskUnmountApproval callback: - Notifies me that someone *wants* to unmount the volume, but does not guarantee that the volume was actually unmounted. In one case I'm working on right now, I'll have an external drive attached. On reboot, I register for the mountApproval and unmountApproval callbacks. The volume is mounted and then I immediately get an unmountApproval callback. If I treat this callback as a sign that the drive actually *was* unmounted, then I would assume that the volume is being mounted and immediately unmounted (within milliseconds) upon startup. That is clearly not the case, since the volume is still attached when I get up into my login session. This is in a LaunchDaemon, and the code has been running the whole time without any further DiskArbitrationCallbacks. Previous answers (including the one I linked to) have suggested looking at the code of the disktool utility. It correctly handles situations like this. It appears, though, that it is using additional information. disktool.c includes <DiskArbitrationPrivate.h<http://www.opensource.apple.com/source/DiskArbitration/DiskArbitration-183/DiskArbitration/DiskArbitrationPrivate.h>>, and calls functions defined there including DiskArbRegisterCallback_UnmountPreNotification and DiskArbRegisterCallback_UnmountPostNotification. That "PostNotification" part looks like what I need in the case of unmounting. Unfortunately, it's in a private header. I could, of course, copy that header into my project, but I would have no guarantee that the API would be stable between Leopard and Snow Leopard, for example. And even though the header is open source and publicly available, I think it still falls into the category of a private API, and thus I'd rather avoid that. The context of all this, since I'm sure someone will ask, is a backup daemon (a LaunchDaemon) which is keeping track of what files are dirty; when a volume is mounted, I need to check to see whether any files on that volume match my rules of what to back up. When a volume is unmounted, I need to update some internal state to stop tracking those files. So, my question: is there a better way to be notified of disk mount/unmount events? If there's a better list for such questions, please feel free to direct me there. I searched on lists.apple.com, and everything relating to DiskArbitration was showing up on Cocoa-dev. Thanks, -BJ Homer _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
