Re: disk operations - mounting images I've created manually via Disk Utility
Re: disk operations - mounting images I've created manually via Disk Utility
- Subject: Re: disk operations - mounting images I've created manually via Disk Utility
- From: Luther Baker <email@hidden>
- Date: Sun, 16 Mar 2014 19:31:45 -0500
The NSWorkspace idea was a great suggestion. I'm actually using my first homegrown OSX app in my everyday work with that suggestion!!
I will continue to refine it ... I wonder though, if it is presumptuous to guess which apps Apple will continue to provide for use from my app. And, does OSX actually use Disk Utility or "hdiutil" to actually mount my bundles. I'm currently ok mounting dmgs or other image types via whatever mechanism the current OS or user preferences dictate so I may opt NOT to specify that in the call to open the file (admittedly I am pretty green in this space) ... but that said,
I think my next step in this app is to encapsulate a bit more sparse file image functionality in my simple app. Namely, I've come across some suggestions to wrap calls to "hdiutil" inside of NSTask as it seems that the DiskImage framework is still pretty private.
Per my original post, I think Disk Arbitration is quickly falling off the radar as a viable option for this work but maybe that will prove incorrect.
Nevertheless, I'm not sure how I feel about I the proposed "call out to the OS" type of programming for hdiutil type functionality. My app won't be able to stand on its own and I think I will feel beholden to Apple a bit.
Maybe hdiutil will forever be available ... Maybe DiskImage, or parts of it, will be made public. Either way, I think it is the only way to get the functionality I'm after next.
I wonder if it would be wise to consider wrapping calls to hdiutil inside of user space Apple script giving me some runtime flexibility?
Many thanks!
-Luther
> On Mar 16, 2014, at 4:13 PM, Michael Starke <email@hidden> wrote:
>
> What might be useful is to not rely on the default application and use openURL:withApplication: to make sure Disk Utility mounts the image, not another tool the user did associate with .dmgs or .sparsebundle
>
>
>> On 16 Mar 2014, at 05:35, Luther Baker <email@hidden> wrote:
>>
>> Indeed!
>>
>> That works perfectly ... as also does its antithesis NSWorkspace unmountAndEjectDeviceAtPath
>>
>> You are nothing short of a genius.
>>
>>
>>
>> On Sat, Mar 15, 2014 at 4:44 PM, Michael Starke <email@hidden> wrote:
>> I might be missing something, but can't you just open the file with [[NSWorkspace sharedWorkspace]openURL:<fileURL>]?
>>
>> ___m i c h a e l s t a r k e____
>> geschäftsführer
>> HicknHack Software GmbH
>> www.hicknhack-software.com
>>
>> ___k o n t a k t____
>> +49 (170) 36 86 1 36
>> email@hidden
>>
>> ___H i c k n H a c k S o f t w a r e G m b H____
>> geschäftsführer - maik lathan | andreas reischuck | michael starke
>> bayreuther straße 32
>> 01187 dresden
>> amtsgericht dresden HRB 30351
>> sitz - dresden
>>
>>> On 15.03.2014, at 21:56, Luther Baker <email@hidden> wrote:
>>>
>>> I'm an iOS developer talking a walk on the OSX side and have a question
>>> about programmatically mounting sparse bundles ... or really just any dmg.
>>>
>>> My experimental project is to write a little statusbar application to mount
>>> and unmount disk images. I've created a few of these images in my own
>>> "Volumes" directory as follows:
>>>
>>> /Users/me/Volumes/me.sparsebundle
>>>
>>> For the time being, I am hard-wiring logic in a menu selection handler to
>>> actually mount these objects.
>>>
>>> I've been digging into Disk Arbitration and I've come up with the following:
>>>
>>> - (IBAction)mountMe:(id)sender {
>>> DASessionRef sessionRef = DASessionCreate(kCFAllocatorDefault);
>>> CFURLRef volumeURLRef = (__bridge CFURLRef)[NSURL fileURLWithPath:@
>>> "/Users/me/Volumes/me.sparsebundle"];
>>> DADiskRef diskRef = DADiskCreateFromVolumePath(kCFAllocatorDefault,
>>> sessionRef, volumeURLRef);
>>> CFURLRef mountPath = NULL;
>>> DADiskMountOptions mountOptions = kDADiskMountOptionDefault;
>>> DADiskMountCallback mountCallback = NULL;
>>> void *context = NULL;
>>> DADiskMount(diskRef, mountPath, mountOptions, mountCallback, context);
>>> CFAllocatorDeallocate(kCFAllocatorDefault, diskRef);
>>> CFAllocatorDeallocate(kCFAllocatorDefault, sessionRef);
>>> }
>>>
>>> *ANY* suggestions, even tangental (especially around memory management) are
>>> fair game here. I'd appreciate any input as I'm just starting to read about
>>> allocation, etc.
>>>
>>> But more to the point, I don't think DADiskCreateFromVolumePath is what I
>>> want. It seems that DADiskRef is NULL when I run this. Clearly, the most
>>> intimidating method in there is DADiskCreateFromIOMedia ... and I'm afraid
>>> that is the one I'm going to have to use.
>>>
>>> And, am I really trying to mount a "disk" as Disk Arbitration understands
>>> it? I'm not yet dealing with things like fstab, etc which I know very
>>> little about -- but should I start digging that way? I did come across a
>>> nice github project <http://tommetge.github.io/VolumeManager/> but
>>>
>>> unfortunately I can't actually find any methods in there to mount ... only
>>> things like umount or eject. Notably, the open source project does use
>>> 'getmntinfo' which leads me to look at the BSD mount man page ... but I
>>> before going there I want to make sure I'm not _supposed_ to do this in
>>> within Disk Arbitration. There is a DADiskCreateFromBSDName which seems
>>> like it might be similar?
>>> Anyway, any thoughts on this? And in general, is this fundamental stuff
>>> covered in exemplary fashion anywhere? Would the OSX Internals books I've
>>> seen dive into this? I'm assuming that if I've encryped my sparsebundle
>>> that I'd be prompted by the OS for my password, which is fine for my first
>>> pass but I'd eventually like to subsume that logic within my app - if for
>>> no other reason than to simply better understand the partition management
>>> frameworks.
>>>
>>> Thanks in advance for even 1 brief minute of your time. I'll begin trying
>>> the alternatives mentioned above in Disk Arbitration.
>>> -Luther
>>> _______________________________________________
>>>
>>> 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
>
>
> ___m i c h a e l s t a r k e____
> geschäftsführer
> HicknHack Software GmbH
> www.hicknhack-software.com
>
> ___k o n t a k t____
> +49 (170) 3686136
> email@hidden
>
> ___H i c k n H a c k S o f t w a r e G m b H____
> geschäftsführer - maik lathan | andreas reischuck | michael starke
> bayreuther straße 32
> 01187 dresden
> amtsgericht dresden HRB 30351
> sitz - dresden
>
>
> _______________________________________________
>
> 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
_______________________________________________
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