By: Scott Doenges - Revised: 2006-06-06 devin


Once you've determined which files/folders you'll need to tweak in order to make the problematic app work with your system setup, there are several potential workarounds, covered here.

For troublesome installers

Use an app like Pseudo or Skeleton Key to open the installer as a super-user. Sometimes this helps avoid problems with installers trying to write to read-only directories. You can also do this manually with the command line with the following command:

sudo path/to/application/Contents/MacOS/app_name

Sample Pseudo Window and Skeleton Key Icon

Aliases and/or symbolic links

Sometimes you can fool applications with aliases or symbolic links to the files they want to write to. Move the files to a user-writable location (such as /Users/Guest/Library/Preferences/), place aliases to these files in their original locations, and try launching the app.

If aliases won't fool the app, try creating symbolic links via the command line: "ln -s /path/to/source/file /path/to/target/file". This will create a symbolic link (which looks and behaves the same as an alias in the Finder) to the source file in the target location. Try launching the app and see if it behaves normally. See below for an example of creating a symbolic link:

ln -s /Users/Guest/Library/Preferences/Freehand 10 Prefs /Applications/Freehand 10/English/Preferences

FreeHand Directory in List View
Note the "Dictionary", "Preferences" and "Settings" items on the right — these are symbolic links to items in the User's Preferences folder.

Mount a read-only disk image as read/write using "hdid -shadow"

If none of the above options will work, you can actually create a read-only Disk Copy image of the application folder, and use the command-line tool "hdid" to mount the image as read-write. This tool creates a "shadowfile" for the image, so that any change that tries to get written back to the image actually gets written to the shadowfile.

To set this up, create a compressed disk image of your app folder using Disk Copy. Mount the image with the following command, and try opening the app from the mounted image (note that if you don't specify a path to your desired shadowfile location, hdid will try to create the shadowfile in the same directory as your disk image, which may not work if you've restricted access to this location):

"hdid /path/to/disk/image.dmg -shadow /path/to/shadowfile"

Sample Terminal Windows with hdid

If your app behaves normally when launched from the disk image, you can then write a dummy AppleScript that mounts your image using "hdid -shadow" then launches the actual application. This way your users will launch the dummy script instead of the app itself. You can make an AppleScript perform shell commands with the "do shell script" command — see the image below:

Sample AppleScript Window

This is a great way to handle troublesome applications (especially Virtual PC) since it ensures that the disk image doesn't actually get modified between different user logins, and you can also save space by distributing a compressed image of your application.

Note that you may need to write a logoutHook script that deletes the shadowfile on logout. The shadowfiles can get quite large if the user spends a long time working with the app.

Include the app in the user's home folder

Depending on your setup, you could include the troublesome application in your user's home folder. In our Labs, the Guest user's home folder gets refreshed at every login/logout. Since Omnipage wants write access to the entire app directory, we simply added the Omnipage folder to our Guest user's template folder.

So when a user logs in, Omnipage gets copied to their Library folder, allowing them to change prefs, scan documents, etc. When the user logs out, that copy of Omnipage gets deleted, and the next user who logs in gets a fresh copy of the app. Kind of a roundabout solution, but it works quite well.

This may not be a solution for large apps since it would slow down login.

Script Cleanup

Depending on your setup, you could allow world right access and use a script to cleanup at login, logout or startup or use a file system maintenance utility like Radmind.

One example, is the latest version of MacLinkPlus Deluxe 14.000 which requires world rights to the directory /Library/Application Support/DataViz directory. But, only needs read rights to the aliases: MacLinkPlus CM Helper, MacLinkPlus Deluxe, MacLinkPlus Modules and license file:sysKas.5560. If there isn't world rights, the software will prompt you to enter license information, and using aliases, symlinks and moving this directory to the user folder doesn't fix it.

So, we used the following perl script at login for a workaround:

@dataviz_ignore_files = ("MacLinkPlus CM Helper", "sysKas.5560", "MacLinkPlus Deluxe", "MacLinkPlus Modules");
$dataviz_erase_folder = "/Library/Application Support/DataViz";
# Empty DataViz world writable folder.
& removeAllFilesInFolderExcept($dataviz_erase_folder, @dataviz_ignore_files);

sub removeAllFilesInFolderExcept {
my ($pathToFolder, @allowedFiles) = @_;
if (! -d $pathToFolder ) {
print "folder doesn't exists";
@currentFiles = getFileFolderList($pathToFolder);
@killMe = ();
$repeat1 = @currentFiles;
$repeat2 = @allowedFiles;
for ($i = 0; $i < $repeat1; $i++) {
$iDie = 1;
for ($j = 0; $j < $repeat2; $j++) {
if($allowedFiles[$j] eq $currentFiles[$i]) {
$iDie = 0;
if ($iDie) {
$repeat1 = @killMe;
chdir $pathToFolder;
for ($i = 0; $i < $repeat1; $i++) {
print "/usr/bin/chflags -R nouchg "$killMe[$i]" ";
print "/bin/rm -rf "$killMe[$i]" ";
system "/usr/bin/chflags -R nouchg "$killMe[$i]"";
system "/bin/rm -rf "$killMe[$i]"";

Email the software developers and MacFixit

When all else fails, sometimes pressure from both the user and from MacFixit (a well-known forum for Mac hardware/software problems) will urge the developers to fix the problem with their application. Doesn't always work, but it's worth a try when you've got no other options.