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
> <michael.sta...@hicknhack-software.com> 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 <lutherba...@gmail.com> 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
>> <michael.sta...@hicknhack-software.com> 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
>> cont...@hicknhack.com
>>
>> ___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 <lutherba...@gmail.com> 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 (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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/michael.starke%40hicknhack-software.com
>>>
>>> This email sent to michael.sta...@hicknhack-software.com
>
>
> ___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
> cont...@hicknhack.com
>
> ___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 (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:
> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
