Re: Finding out that a volume is going away before it does
On 28 Oct 2008, at 05:26, Chris Suter wrote: On Tue, Oct 28, 2008 at 1:50 AM, Francis Devereux <[EMAIL PROTECTED]> wrote: 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. You can use it fine on 10.3. As far as I know, there was no change to the interface between 10.3 and 10.4 (or none that will bother you). You just need to make sure you link to the framework in /System/Library/PrivateFrameworks rather than /System/Library/Frameworks. NSWorkspace will ultimately be using DiskArbitration; there's no other way for it to work. You're right, I updated my test project to use install_name_tool to change the reference to /System/Library/Frameworks/ DiskArbitration.framework to /System/Library/PrivateFrameworks/ DiskArbitration.framework and it works on 10.3.9. Updated version at http://www.devrx.org/software/osx/DiskArbitrationTest.zip in case anyone wants to have a look. Francis ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
On Tue, Oct 28, 2008 at 1:50 AM, Francis Devereux <[EMAIL PROTECTED]> wrote: > 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. You can use it fine on 10.3. As far as I know, there was no change to the interface between 10.3 and 10.4 (or none that will bother you). You just need to make sure you link to the framework in /System/Library/PrivateFrameworks rather than /System/Library/Frameworks. NSWorkspace will ultimately be using DiskArbitration; there's no other way for it to work. -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
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 (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
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. The full project is at http://www.devrx.org/software/osx/DiskArbitrationTest.zip
, here's the important bits:
@implementation FDDAController
static DADissenterRef DiskUnmountApprovalCallback(DADiskRef disk, void
*context)
{
//FDDAController *self = (FDDAController *)context;
OSStatus status;
OSErr err;
CFDictionaryRef diskDescription = DADiskCopyDescription(disk);
NSLog(@"DiskUnmountApprovalCallback diskDescription = %@",
diskDescription);
NSDictionary *nsDiskDescription = (NSDictionary *)diskDescription;
NSURL *volumeURL = [nsDiskDescription valueForKey:@"DAVolumePath"];
if (![volumeURL isFileURL])
{
NSLog(@"Error: volume URL %@ is not a file URL!", volumeURL);
goto EXIT1;
}
NSString *volumePath = [volumeURL path];
const char *utf8VolumePath = [volumePath UTF8String];
FSRef volumeFSRef;
if ((status = FSPathMakeRef((UInt8 *)utf8VolumePath,
&volumeFSRef, (Boolean *)NULL)) != noErr)
{
NSLog(@"FDPathMakeRef error: %d", status);
goto EXIT1;
}
FSCatalogInfo catalogInfo;
if ((err = FSGetCatalogInfo(&volumeFSRef, kFSCatInfoVolume,
&catalogInfo, NULL, NULL, NULL)) != noErr)
{
NSLog(@"FSGetCatalogInfo error: %d", err);
goto EXIT1;
}
FSVolumeInfo volumeInfo;
if ((err = FSGetVolumeInfo(catalogInfo.volume,
0, NULL,
kFSVolInfoGettableInfo, &volumeInfo,
NULL,
NULL)) != noErr)
{
NSLog(@"FSGetVolumeInfo error: %d", err);
goto EXIT1;
}
NSLog(@"totalBytes = %llu, freeBytes = %llu, blockSize = %u",
volumeInfo.totalBytes, volumeInfo.freeBytes, volumeInfo.blockSize);
EXIT1:
CFRelease(diskDescription);
return NULL;
}
- (void)awakeFromNib
{
NSLog(@"FDDAController awakeFromNib");
daApprovalSession = DAApprovalSessionCreate(kCFAllocatorDefault);
DAApprovalSessionScheduleWithRunLoop(daApprovalSession,
[[NSRunLoop mainRunLoop]
getCFRunLoop],
kCFRunLoopCommonModes);
DARegisterDiskUnmountApprovalCallback(daApprovalSession,
NULL,
&DiskUnmountApprovalCallback,
(void *)self);
NSLog(@"finished registering callbacks");
}
- (void)dealloc
{
DAUnregisterApprovalCallback(daApprovalSession,
DiskUnmountApprovalCallback, self);
DAApprovalSessionUnscheduleFromRunLoop(daApprovalSession,
[[NSRunLoop mainRunLoop]
getCFRunLoop],
kCFRunLoopCommonModes);
CFRelease(daApprovalSession);
[super dealloc];
}
Francis
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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]
Re: Finding out that a volume is going away before it does
On Oct 27, 2008, at 8:42 AM, 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? I think you're putting too much stock into this ordering. Think about it: how do you think NSWorkspace arranges to learn about volume unmounts in order to deliver the notification? It probably registers a callback with DiskArbitration. If so, then the fact that it is delivering its unmount notification before your callback gets called is probably just due to the order in which the callbacks were registered. Both your code and NSWorkspace are probably responding to the same mechanism. 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. So what? Why do you care about this ordering? Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
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. Greg ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
On 27 Oct 2008, at 12:30, Gregory Weston wrote: The documentation you attached included a caveat that the volume reference number I'd receive isn't useful for anything except comparison against cached data. Can't use FSGetVolumeInfo. The assumption being that you already have a cache of vRefNums and whatever info you need from their FSGetVolumeInfo calls. Perhaps if you mention what you are actually trying to do we might be able to find a better/simpler solution. Matt ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
On Oct 27, 2008, at 4:37 AM, [EMAIL PROTECTED] wrote: On 26 Oct 2008, at 17:37, Gregory Weston wrote: 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. Greg It look to me like registering for kEventClassVolume / kEventVolumeUnmounted carbon events would do what you need. This will tell you the cRefNum of the unmounted volume (once again though after it had gone). The documentation you attached included a caveat that the volume reference number I'd receive isn't useful for anything except comparison against cached data. Can't use FSGetVolumeInfo. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: Finding out that a volume is going away before it does
On 26 Oct 2008, at 17:37, Gregory Weston wrote:
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.
Greg
It look to me like registering for kEventClassVolume /
kEventVolumeUnmounted carbon events would do what you need. This will
tell you the cRefNum of the unmounted volume (once again though after
it had gone).
Matt Gough
* kEventClassVolume / kEventVolumeUnmounted
*
* Summary:
*An existing volume has been unmounted (or media ejected).
*
* Discussion:
*This event is sent to all handlers registered for it.
*
* Mac OS X threading:
*Not thread safe
*
* Parameters:
*
*--> kEventParamDirectObject (in, typeFSVolumeRefNum)
* The volume refnum of the volume that was unmounted. At the
* point when this event is sent, this is no longer a valid
* volume refnum, and cannot be passed to any File Manager
* API; it is useful only for comparison with cached volume
* refnums in your own data structures.
*
* Availability:
*Mac OS X: in version 10.0 and later in Carbon.framework
*CarbonLib:in CarbonLib 1.3.1 and later
*/
enum {
kEventVolumeUnmounted = 2
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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]
