• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Finding out that a volume is going away before it does
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding out that a volume is going away before it does


  • Subject: Re: Finding out that a volume is going away before it does
  • From: Francis Devereux <email@hidden>
  • Date: Mon, 27 Oct 2008 14:50:00 +0000

On 27 Oct 2008, at 13:42, Gregory Weston wrote:

On Oct 27, 2008, at 9:31 AM, Francis Devereux wrote:

On 26 Oct 2008, at 16:37, Gregory Weston wrote:

Amusingly, when you register an unmount or eject approval function with DiskArbitration, that function gets invoked *after* NSWorkspace sends its didUnmount notification. How's that for a lead-in anecdote?

So anyway, I'm looking to react to the imminent or even potential departure of a volume. Some way I can know that a volume will (or probably will) be taken away from me in the near future but with enough lead time that I can reliably make one or two quick function calls against it. Any thoughts? I'm not worried about abrupt disconnects like the user yanking the cable on an external drive. Just looking for the tiniest smidgen of warning for orderly unmounts.

Specifically, I'm looking for the opportunity to call FSGetCatalogInfo on the mount point and then FSGetVolumeInfo on the volume reference number I got back from the first call.

Have you actually tried using DiskArbitration unmount approval callbacks? I decided to give it a go and was able to successfully call FSGetVolumeInfo in the callback. Tested with OS X 10.5.5 and Xcode 3.1.1.

I did; that's how I noticed that the approval callback happened after the unmount notification. My test case was on a 10.4 machine and I actually need to support 10.3+. If it's something they've only fixed some time in the last year it's not especially helpful to me today. But I appreciate the data point.

My code works on 10.4 8A428 PPC (after I changed mainRunLoop to currentRunLoop), but this probably isn't much help to you because DiskArbitration.framework is private on 10.3. Probably best to follow Matt Gough's suggestion of caching the info from FSGetVolumeInfo before you get the kEventVolumeUnmounted carbon event.


Francis.
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Finding out that a volume is going away before it does
      • From: "Chris Suter" <email@hidden>
References: 
 >Finding out that a volume is going away before it does (From: Gregory Weston <email@hidden>)
 >Re: Finding out that a volume is going away before it does (From: Francis Devereux <email@hidden>)
 >Re: Finding out that a volume is going away before it does (From: Gregory Weston <email@hidden>)

  • Prev by Date: Re: Finding out that a volume is going away before it does
  • Next by Date: Documentation of NSArchiver streamtyped format
  • Previous by thread: Re: Finding out that a volume is going away before it does
  • Next by thread: Re: Finding out that a volume is going away before it does
  • Index(es):
    • Date
    • Thread