At 03:06 -0800 24/02/09, cocoa-dev-requ...@lists.apple.com wrote:
>From: Tommy Nordgren <tommy.nordg...@comhem.se>
>References: <67c1da73-c3cb-4854-9b46-70c0365d5...@mac.com>
> <57b2a86d-b87c-486f-8d2e-6291d3f29...@comhem.se>
> <4b898f01-2234-4d19-8b63-25f4cd275...@webis.net>
> <15c43c09-ae0d-455e-ae10-5bc8c2714...@comhem.se>
> <d73dcbd60902231834s26b34728h6c5fa6b3ac209...@mail.gmail.com>
>In-Reply-To: <d73dcbd60902231834s26b34728h6c5fa6b3ac209...@mail.gmail.com>
>Date: Tue, 24 Feb 2009 04:08:36 +0100
>Message-ID: <8d535551-d24a-47ad-8fa2-2138ca7ec...@comhem.se>
>
>On Feb 24, 2009, at 3:34 AM, Shawn Erickson wrote:
>
>>On Mon, Feb 23, 2009 at 6:22 PM, Tommy Nordgren
>><tommy.nordg...@comhem.se> wrote:
>>>The following code will test if you are running from the DMG:
>>>
>>>NSString * volName = @"Mother";
>>>NSString * appName = @"MyApp.app";
>>>
>>>if ([[[NSBundle mainBundle] bundlePath] isEqualTo: [ NSString
>>>stringWithFormat:@"/Volumes/%@/%@",volName,appName]) {
>>>
>>> //Here you can show an alert telling the user to to copy the app to
>>>the applications folder
>>>
>>>}
>>
>>If a disk image it mounted a second time (can happen in a few ways) it
>>won't be at /Volumes/Mother/... but at /Volumes/Mounter 1/... Also you
>>can mount disk images in location other then under /Volumes/...
> It will be /Volumes/Mother 1/... I've tested.
>This can be handled by using a regexp class for the matching instead of a
>simple
>equality test.
> Also, while it's possible to mount a disk image at other places than
> under Volumes,
>that won't happen when doubleclicking a disk image or it being mounted from
>Safari
You might want to look at
http://www.brockerhoff.net/src/index.html
scroll down to "PathProps". It's source code I wrote to check volume/device
parameters for a given path; the original idea was to check whether your app is
running from a disk image. (Some of the code to find out details for a network
volume calls deprecated API's; you might want to comment that out.)
In fact, I don't recommend using this code directly; use parts and modify as
you see fit. For one, if your app is in ~/Applications and the user is using
FileVault, the home folder _will_ be on a disk image. So you'll also have to
check if the volume is read-only r not.
It may be useful to also distinguish whether you're running from a generic disk
image or optical disk, or specifically from _your_ distribution disk image. For
that, I found it most useful to have a hidden file next to my app on the
original image. This hidden file has a name like
".29E04275-96F1-4CF5-9EB5-4ECE6908C460.png" (make your own UUID in the Terminal
typing "uuidgen"), and doubles as the disk image's hidden background image.
Then I simply check for the presence of this file.
What action to take depends on what your software does. If you have to install
a launch agent or setuid/setgid tool, these binaries won't work properly from
FileVault or on a disk image, so you pretty much have to handle this case.
Personally I avoid installer packages - I've lost data in the past by
improperly quoted folder paths in installer scripts, and dislike writing shell
scripts myself. An alternative is to do a one-time check; have a "first run"
key in your preferences, and if the user is running from the dmg, you offer to
copy the application.
Previous posts have discussed the problem of "moving" a running application.
This is actually unnecessary. You can copy your entire application bundle with
an API like FSPathCopyObjectSync() or one of the Cocoa equivalents, start the
copy with LaunchServices, quit, and have the copy unmount the disk image.
While I'm not sure I was the first to use the symlink-to-Applications
technique, I started using it in 2003 (see http://db.tidbits.com/article/8357).
If you use it, be sure to use a symlink instead of a Finder-generated alias
file; besides being larger, an alias may contain private data about your home
system, like the name and creation timestamp of your boot drive.
Downside of the symlink idea is that there's no way to make a generic symlink
to ~/Applications.
HTH,
--
Rainer Brockerhoff <rai...@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
Weblog: http://www.brockerhoff.net/bb/viewtopic.php
_______________________________________________
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 arch...@mail-archive.com
