2012-08-04

BOX — A way to manage the Mountain Lion Inbox

This method involves creating one ordinary mailbox, called Hold, in the IMAP account of your choice, and a smart mailbox. The smart mailbox, called “Box” contains messages matching “any” of the following conditions: “Message is Unread”; “Message Has Flag Red/Orange/Yellow”; or “Message is in Mailbox “Inbox”. Do not include either Trash or Sent. Drag both Hold and Box to the bookmark bar. In View>Message Attributes, make sure that “Flags”, “Mailbox”, and “Date Received” are selected. Above the message list display, select “Sort by Flags ▾” and “Ascending”.

At this point, instead of viewing your Inbox, you should view Box. You will see unread messages and Inbox messages at the top, followed by all red-flag messages, then orange-flag messages, then yellow-flag messages. Within each level, you'll get the same default sorting by priority and date, oldest first. Note that messages flagged at a lower priority (Green-Grey) can be viewed via the standard Flagged bookmark (this bookmark should also be set up to sort by Flags  ▾, ascending). Normally, all messages in Hold will be flagged, but the Hold bookmark can be selected to see all current contents, flagged or not.

In addition to this, you should drag the root of your current mailbox archive hierarchy to the bookmark bar (in my case, this is currently named y2012). This should allow you to keep the mailboxes sidebar hidden most of the time.

When a message arrives, it will be at the top of the column. Here is a suggested sequence for dealing with a message in your Inbox.
  • Delete it if you can, possibly after jotting down a quick reply (the rule is, less than two minutes).
  • If you need to act on it, but it will take longer than two minutes, set a flag according to its priority. Then...
    • If you're not sure where or whether you want to save it after you've dealt with it, drag it onto the Hold bookmark.
    • If you already know where to save it, drag it onto your archive bookmark and down to the appropriate mailbox.
Once your Inbox has been cleared, then at your leisure, you can deal with your flagged messages. When you have finally dealt with one, set its flag to “None”. If the message is located in Hold, just delete it (or you can decide to archive it).

If you need to deal with a message on a certain date, drag it to iCal on that day, and consider setting an alert. If you tend not to look at iCal regularly, I recommend a utility called EmailMyCal from the App store: it can email you your agenda, including a mention of pending email, each day. You will also receive (OS/X ≥ Mountain Lion) alerts about that message, depending on your configuration.

OK, that's the system. You really need to keep unread/Inbox messages low, or you won't see the flagged messages.

2012-06-06

BOX -- [NOT] a simple inbox management scheme

****IGNORE THIS****
Due to an extremely annoying lack in Mail.app, the critical “Date last viewed/Not in the last...” filter simply doesn't work. Sorry.

The Box: How to keep a clean Inbox (OSX Lion)
It is very common to use the Inbox as a To Do list or reminder system. Once a message has been dealt with, it is either deleted or archived into a folder somewhere. The problem is that sometimes you can get behind--sometimes very behind--and the Inbox gets filled with messages that you promise yourself that you will deal with.
Here is an approach to dealing with this problem using Smart Mailboxes and the seven Message Flags. I implemented it on Lion, but it will probably work on most OS/X versions.
HOW TO SET IT UP
First, although the underlying interpreter is apparently capable of dealing with complicated rule systems for Smart Mailboxes, the user interface is not. In particular, there is no direct way to deal with situations like (X and Y) or (A and B). The indirect way of dealing with this is to create a Smart Mailbox XY that contains all messages meeting criteria X and Y and a second one AB with messages meeting criteria A and B. Then the whole thing can be represented by a third Smart Mailbox XYAB meeting XY or AB. In order to make this less busy, we will create a Smart Mailbox Folder and call it “zzz” so it will sleep peacefully at the end of the list of Smart Mailboxes.
Second, we will create a whole set of individual Smart Mailboxes and move them into zzz. The list is:
  • BoxToday (red)
  • Box1day (orange)
  • Box2day (yellow)
  • Box3day (green)
  • Box1week (blue)
  • Box2week (purple)
  • BoxAnyFlag (gray)
  • BoxUnread
  • BoxOldTMP
These will contain rules such that the message will be in the Smart Mailbox if it has been flagged with the color indicated and if has not been read in the number of days or weeks indicated (BoxToday just depends on their being a red flag). For example Box2day has two conditions: Date Last viewed is not in the last 2 days; Message has Flag Yellow. BoxAnyFlag will always apply if any flag is set and if the message has not been read in a month. BoxUnread applies to all unread messages. Note that I chose the lags (0-1-2-3 day, 1-2 week, 1 month) arbitrarily, based on the notion that you'll want to push things back a short time more often than a long time, and that a monthly review of pushed-away mails is about right. But these can be set to whatever you want—for example, 0-1-2-3-4-5-6 days plus weekly reviews of unread and _TMP would also be perfectly logical, and there are other possibilities as well. Note that the colors are assigned an increasing lag as a function of their position in the flag menu button (red to gray).
Next, create a Smart Mailbox called Box. Unlike the others, it will apply if *any* rule applies. The rules it contains are “Message is in Mailbox X”, where X is all of the above Smart Mailboxes, plus Inbox (the common inbox for all accounts). Do not move this Smart Mailbox into the zzz folder. However, you should drag it up into the shortcut row along with Inbox, Drafts, Sent, and so on. It will stick up there for easy access.
Create a regular mailbox called _TMP and put it somewhere convenient. This will be used to contain miscellaneous messages that will not be archived but that you must deal with in the future. It may be convenient to add this as a shortcut next to Box. Be careful not to let the _TMP folder contain messages without flags. If you delete the flag, also delete (or refile) the message. Note that the BoxOldTMP Smart Mailbox will include any message in _TMP that hasn't been read in a month or more.
Optionally go into the View>Message Attributes menubar item and make sure that Mailbox is checked. This is very useful when looking in the Box because it will show you where each message is currently stored. You might also check either Date Sent or Date Received; this will help you distinguish old, recycled messages from new ones. Also, it is critical that Flags is checked here.
HOW TO USE IT
Once you have the infrastructure set up, you should click on the Box shortcut. You will see all of your current Inbox contents plus probably a bunch of old unread messages, and perhaps some previously flagged message. You *must* go through these, weeding out stuff you don't want, filing things that have been dealt with, and flagging and filing everything else. At the end, you will have an empty Inbox and no unread messages anywhere. If you come across a message you want to deal with but not file, put it into the _TMP folder, that's what it's for.
Now, instead of looking in the Inbox for new mail, look at Box. When a message arrives in the Box, either:
  • Deal with it, remove its flag if any, and delete it
  • Deal with it, remove its flag if any, and file it
  • Flag it with a (different) priority and file it
But never leave it in the Inbox. Note that when you flag a message with a Red flag, it will always show in the Box, regardless of whether it was filed. Similarly, after a day has passed, a message flagged with an Orange flag will show again, but will go away once you have looked at it again. Any message with a flag will show back up at least once a month.
It is also useful to add a few other shortcuts to the top of the window, for example, the current year's receipts folder (i.e., receipts2012). The shortcuts are especially useful in that in Lion, the mailbox hierarchy can remain hidden most of the time.
THE BUILT-IN FLAGGED FOLDER
There is a standard “Flagged” smart folder that you can use to look at all flagged messages if you forget where you put one. Note that this will show flagged messages that are in the trash, which is why you should remove the flag before deleting a previously flagged message.
AUTOMATIC FILING
In some cases, it is possible to file messages from certain recipients automatically with an incoming mail rule. This approach meshes extremely well with the Box approach. If you simply file such messages, then they will show up in the Box because they have not been read. However, if you “accidentally” read them (while browsing in Box) then they will not show up again. To help with this, you could also have the rule give them a flag, for example the Red or Orange flag, to make sure you see it.
USING iCal
In some cases, you don't want to just push back an email to some rough time in the future, you must deal with it by a specific but far-off deadline. The Box method is not for that. Instead, file the message and then drag the message to a date and time in iCal. This will make the reminder part of your regular calendar system.

2012-03-19

Post-iDisk backups

Apple supplies a program called Backup.app, formerly available on to those who had mac.com memberships, but later available generally. This program was intended for backing up relatively small but critical information to the iDisk. It could also be used to back up to network drives on the LAN, and to drives attached directly to the Mac. However, the iDisk is now going away, to be replaced by iCloud. But there is a difference between the kind of backup done via iCloud and the kind done by Backup to the iDisk, in that the new iCloud backups are intended to include a very wide range of things, where Backup could be used to make very specific, possibly redundant backups of selected things only. I wanted to have something that could be used to replace the functionality of the iDisk as a place to store selected files, and as a destination for a Backup-like automated backup of selected elements.
I selected the free service offered by CloudSafe GmbH as the replacement iDisk. They offer 2 GB for free. Their site is very secure in that all access is via https, and all data stored there is highly encrypted and must be decrypted through the use of a lengthy key. Also, they offer WebDAV over https to the data.
The free CloudSafe accounts can have up to three WebDAV mountable remote drives, called “safes”, each with its own encryption key and access rules. For the purposes of backup, I created a safe called “Backup”.
In order to use the remote drive, you first have to use CloudSafe's dashboard to enable WebDAV on the safe. When you do this, the system will display two critical codes. The first code is part of the address used to access the drive, and is a 10-digit number, like « https://0123456789.webdav.cloudsafe.com/ ». The second code is used, along with the e-mail address you use to access your CloudSafe data online, to get access (i.e., decrypt) the data. The other code consists of four six-character alphanumeric strings, like ACB123-DEF456-GHI789-JKLMN0.
When you have received those codes, the first thing to do is to use Finder's CMD-K option to open the safe. It may be necessary to have some content in the safe for it to open correctly. In my case, I created a folder called Daily there. When you go through Finder's authentication protocol, enter the full https address as the device, the email address as the login name, and the decryption string as the password. IMPORTANT: save this in your login keychain.
Now, some of what follows can be done differently if you prefer, but this is what I did.
I have a miniature partial unix-style file system called “usr” under Documents in my home directory. I put it there to keep it relatively unobtrusive and to avoid cluttering the main file system. In what follows, it is assumed that the folder “~/Documents/usr/libexec” exists to contain the script.
Next, the script itself:


#!/bin/ksh
# backs up a list of folders or files to the CloudSafe Daily folder.
# The backups are done in subfolders of Daily as follows: there is a
# folder for every month (%m; 01-12) in every year (%Y). The backup is
# done there whenever the corresponding folder (%Y%m) doesn't exist.  On
# all other days, the backup is done in a 7-day cycle based on the day
# of the week (%u; 1-7; Monday = 1). All previous contents (if any) are
# removed before each backup.

# NOTE: the CloudSafe file system is very simple and does not support
# links and so on, so nothing complicated should be backed up here. all
# are below $HOME. If it becomes necessary to backup more complicated
# filesystem structures, maybe we can backup using tar or a disk image

Me=`basename "$0" .ksh`

# server info
SAFE=0123456789 # REPLACE THIS WITH YOUR SAFE'S INFORMATION
SERVER=webdav.cloudsafe.com
URL="https://$SAFE.$SERVER/Daily"
# mountpoint info
MNT=/Volumes
DEST="$MNT/Daily"

Year=`date +%Y`
Month=`date +%m`
Day=`date +%u`

# try a command n times or until success
function tryrep {
 typeset i ntry=$1 ; shift ; typeset cmd="$@"
 for (( i=0 ; i<$ntry ; i++ )) ; do
  if $cmd ; then return 0 ; fi
  sleep 10
 done
 return 1
}

log(){
 print -- "$Me: $*" | logger -s
}
err(){
 log "$*"
 exit 1
}
errum(){
 if tryrep 100 umount "$DEST" ; then
  sleep 5
  if [[ -d "$DEST" ]] ; then
   rmdir "$DEST"
  fi
 fi
 err "$*"
}

# the list of assets
set -A Src \
 Library/Keychains/personal.keychain \
 Library/Keychains/login.keychain

# mount volume
if ! mkdir "$DEST" ; then
 err "Mountpoint '$DEST' is in use or $MNT is unwritable"
fi
# assumes that authentication is in user's keychain & mount_webdav has access
if ! tryrep 10 /sbin/mount_webdav "$URL" "$DEST" ; then
 rmdir "$DEST"
 err "Failed to mount '$DEST'"
fi

log "Mounted '$URL' at '$DEST'"

# establish and zero the destination folder
if [[ ! -d "$DEST/$Year$Month" ]] ; then
 Dest="$DEST/$Year$Month"
else
 Dest="$DEST/$Day"
fi
rm -rf "$Dest"
mkdir "$Dest"

for (( i=0 ; i<${#Src[*]} ; i++ )) ; do
 where=$(dirname "${Src[i]}")
 mkdir -p "$Dest/$where"
 if ! cp -Rp "$HOME"/"${Src[i]}" "$Dest/$where" ; then
  errum "Copy returned an error (${Src[i]})"
 fi
 log "Copied '${Src[i]}' to '$Dest/$where'"
done

log "Backup complete"

if tryrep 100 umount "$DEST" ; then
 sleep 5
 if [[ -d "$DEST" ]] ; then
  rmdir "$DEST"
 fi
else
 err "Problem unmounting $DEST"
fi
log "Unmounted '$DEST', exiting"
exit 0

This script should be copied and pasted into a file (look it over for random HTML character entities that might get inserted), and saved as something like « cloudSafeDaily.ksh » in ~/Documents/usr/libexec. Use the « chmod +x » command to make it executable. Note that you must REPLACE the 0123456789 with YOUR SAFE's 10-DIGIT CODE.
The version of the script above backs up only your main login keychain plus a “personal” keychain, but you can alter the « Src » array to contain what you want to include. These can be either files or folders. Note that they shouldn't include symlinks or Finder aliases, because those aren't supported in the CloudSafe filesystem.
Next, use the crontab -e command to create an entry in your personal crontab like this:
30 2 * * * ~/Documents/usr/libexec/cloudSafeDaily.ksh
In the example, this  will run the above script at 2:30 AM every day. Take a look at the documentation in crontab(1) and crontab(5) for more information about how you can set this up to run.
Basically what it does is to try (heroically) to mount your Backup safe at the indicated time. It figures out the year, month, and the day of the week by using the date(1) command. It looks to see if there is a long-term backup already for the year and month (for example, /Volumes/Daily/201203) and if there isn't, it will use that as the destination; otherwise, it will use the day of the week (for example, /Volumes/Daily/1) as the destination. Then it copies the indicated data into the destination (after first removing whatever was there before), creating all folders in the paths as needed. For example, in the example it will create (e.g.) /Volumes/Daily/1/Library/Keychains/login.keychain along with the Library and Keychains folders. This folder-creation is necessary in order to prevent files of the same name in different folders overwriting each other.
This will allow you always to go back 7 days, plus it will keep one backup per month as long as you let it run.
It does not check for space, because the WebDAV filesystem doesn't support that feature correctly. So, it will keep going until you get an error, which shouldn't be a problem if you use this only for smallish files. If the script works normally, there will be a few lines of information written to the system log; if there are errors, a descriptive log entry will be made to help you try to pinpoint the problem.

Why did I make the login and personal keychains the default items to backup?
There is a bunch of critical information in the login keychain, plus, you can store texts in there as encrypted secure notes. You can use this for all of my password information and various other important, secret information.
Note that secure notes do not unlock automatically by default, but some passwords do. Also note that the password for the login keychain is normally the same as your login password and some feel that this is a security problem. If you think this, then my advice is to create a second keychain file, which I call « personal.keychain », for example. Put things that are unlikely to be needed by programs, such as your secure notes and certain passwords and certificates, and give it its own, different password. I added this to the nightly backup on a line before « Library/Keychains/login.keychain » that says « Library/Keychains/personal.keychain \ ». They will both be backed up. Note the backslash at the end of the non-final line: this is critical. Another option would be to remove the final « /login.keychain » from the existing line; this will cause the entire Keychains folder to be backed up, no matter how many keychains you have in there (I didn't do that by default because sometimes a lot of useless files can accumulate in the Keychains folder).
UPDATE: It turns out that in order for the crontab process to get access to the information in the keychain, it must be added to the System keychain, and access must not be restricted. This doesn't seem acceptable to me.

2009-07-07

/etc/profile

The system-wide sh-class shell initialization file can be very useful, but there are some potentially confusing aspects of how it is used in different shells. The goal is to have a reasonable version of /etc/profile that can be used for all users.

Classic sh shell.

The Bourne shell as described in the BSD 4.4 User's Reference Manual distinguishes between "interactive shells" (stdin is a terminal or -i flag was used); "login shells" (0th argument begins with '-' (e.g., "-sh"); and other invocations. Login shells evaluate /etc/profile and .profile if they exist, non-login shells skip this step. Then for every shell invocation, if the environment ENV is set, its contents are interpreted as a path that is then evaluated. Note that for non-login shells, ENV must already be in the environment; for login shells, it may be set in one of the profiles. Interactive shells can be identified by using case $- in *i* ) ... ;; ... esac.

Bash shell.

This is the default OS/X shell and is the most widely used descendant of the Bourne shell. It behaves differently when it is invoked as "sh" or "bash". In the former case, its startup is intended to emulate that of the classic sh (note that this mode is used in single-user mode and in many shell scripts intended to be widely compatible). For bash, an interactive shell is one whose stdin and stdout are connected to terminal, or if the -i flag was used. A login shell is one whose arg0 starts with - ("-bash", "-sh"), or where the --login (or -l) flag was used. When bash is invoked as "sh", it first evaluates /etc/profile and then ~/.profile unless --noprofile is given. Note that the --login can be used even with "sh" invocation. At this point, "sh"-invoked bash enters "posix mode" (the --posix flag can also be used for this purpose). In posix mode, ENV is handled as with classic sh. When bash is invoked as "bash", it also evaluates /etc/profile, then the first existing file in the set ~/.bash_profile, ~/.bash_login, and ~/.profile (unless --noprofile was given). Interactive, non-login bash evaluates ~/.bashrc, unless --norc is given. Non-interactive bash evaluates $BASH_ENV if defined. Note that for interactive bash shells, $- will include i and PS1 will be set. In bash, the following variables will be set by the shell: BASH, BASH_VERSINFO (array), BASH_VERSION.

Korn shell.

This is an excellent extended version of sh which differs from bash in various ways. Ksh defines interactive the same as bash, but it has no effect on the startup files used. Login shells are defined as for sh: arg0 must begin with '-' (e.g., "-ksh"). Login shells evaluates /etc/profile if it exists, and then .profile or $HOME/.profile, if either exists. As for ENV, it is handled the same as classic sh, except if it is not set, $HOME/..kshrc will be evaluated if it exists. If the real and effective uid or gid do not match, /etc/suid_profile will be used instead of ENV or HOME/.profile (interactive shells). Also, in ksh $- contains i. In ksh, the variable KSH_VERSION will be set by the shell.

Single user mode

On standard UNIX-style systems, either /bin/csh or /bin/sh are used in single-user mode. If /bin/csh, we are already forked, but if /bin/sh, then there are consequences for /etc/profile, because it will generally by evaluated in single-user mode (in the current launchd under OS/X, it is invoked as /bin/bash, with arg0 set to "-sh"). Functionally similar invocations are probably the norm.

Some conclusions

Basically, /etc/profile will be evaluated for all logins. If ENV is set, then in some cases but not all, it will be evaluated, and of course there are some other shell-specific files that also will be evaluated in some cases, that we aren't concerned with here. There is no simple test to detect the currently running shell. One can use $0, but that doesn't distinguish true sh from one of the others masquerading as sh. However, that may not matter in many cases. Therefore, a simple case statement on $0 will work in most cases in /etc/profile. The situation in ENV is more complicated, because there could be an unknown amount of environment setting (e.g., for PS1) before ENV is run. In one case I know of, the login shell is ksh, and it is detected correctly, and then ksh-specific material is placed in PS1. If bash is then run interactively from the ksh login session, it *inherits* PS1. The fix is to put stuff in ~/.bashrc to set up PS1, or to do other things where bash and ksh differ.

2009-06-22

Scripting single-user mode

As I have written earlier, it was possible to add commands to /etc/rc.server, and they would be executed in a context very similar to single-user mode. However, with the the 10.5.7 upgrade, /etc/rc.server was moved to a later point in the boot sequence, to an environment more similar to ordinary multi-user mode. So not only is the context different, but this indicates how fragile the whole /etc/rc* vestige is in OS/X. A new method is required.

The best alternative I've come up with is to use actual single-user mode. It is possible to get into single-user mode from a script via this sequence (executed as root): « nvram boot-args=-s » ; reboot. At some point once single-user mode is entered, the command « nvram boot-args= » must be run in order to re-eneable multi-user mode.

There is a script that is executed by the shell, and that can be hooked for the purpose of scripting maintenance in single-user mode: /etc/profile, the shared, system-wide start-up file for all shells in the sh family. However, since this location can (and should) be used to customize the shell environment at the system level for all users, it should be changed as "invisibly" as possible.

I prefer to deal with these issues as follows: I'll put one line at the top of /etc/profile that contains some fast heuristics and slower deterministic tests for single-user mode which if passed result in a call to jidaemon (which is the script I want to run in single-user mode). The presence of this line at the top of /etc/profile is required. It can be checked by comparing [[ "$THELINE" == `head -1 < /etc/profile` ]]. The heuristics should all be based on the shell's internal environment, and should be as fast as possible, because /etc/profile is called every time the shell starts up. The heuristics are UID=0, HOME=""; if those are true, the deterministic tests are `sysctl -n kern.singleuser`=1 and -x /var/root/jidaemon. If those are true, run /var/root/jidaemon. Within jidaemon, all those tests are repeated, and some additional tests are run: nvram boot.args == *-s*, read-only root, -f /tmp/just.imagine and so on. Also, if -s is set in nvram boot.args, jidaemon must clear it while preserving any other flags. If any of these tests fail, then jidaemon returns to caller and the only result (beyond clearing the boot.args -s flag) is a slight delay--the shell will continue and an interactive single-user mode session will begin. If jidaemon runs normally, it will restart the system when complete.

2009-01-27

Importing SSL certificates on OS/X leopard server

I'm not going to go through the whole process, which is well-documented elsewhere. Basically, you buy & download the ssl.crt (certificate/public key), ssl.key (private key--I go passwordless, but YMMV), and ca.pem (certificate authority) files and then click on "Certificates" in Server Admin, browse to their locations, and install them. My problem was related to the fact that last year, when I first got certs from startcom, their master ca was not listed in the standard list of signing authorities on the server. I tried a lot of ways to get around that, and eventually got it working without really understanding why. My trick was to install the certs manually into /etc/certificates and use "custom configurations" in each ssl service. Recently when I had to renew the certificate, I had to revisit the whole mess. When I tried to import the renewed certificates, I put them into /etc/certificates as before, but after each reboot, the old ones would keep getting written on top of them. This undoubtedly was happing last year, but I didn't realize it because I only had one set of certs. I eventually decided that the only place the old ones could be coming from was the system keychain.

I looked in the system keychain and tried to install the new ones there, but kept getting an error saying the the identity already existed.

It turns out that in fact, the server copies certificates from the keychain into /etc/certificates at boot time. I hadn't known this. When I deleted the certificates from the keychain, everything "just worked" after I installed the new certs into /etc/certificates. The missing piece of the puzzle was the server scribbling in /etc/certificates.

Chapter three of this (in progress) is that now the startcom signing authority cert is in the server's default list. I verified this on a new install of the server software--on that system, the standard Server Admin approach works flawlessly, no direct access to /etc/certificates is needed at all. So, the next step on the older system is to turn off all ssl services (at least iCal, iChat, Mail, OD, RADIUS, VPN, and Web), clean out /etc/certificates, and install the up-to-date certs into Server Admin. Then, go through each service and ditch the custom configurations, replacing them with the standard wildcard cert installed normally.

OK, I think I've done this successfully: it seems to be working. So, the comment about the server scribbling in /etc/certificates no longer is relevant to my particular configuration, but it is very relevant to someone who has a custom configuration. My advice: go ahead and put the certs in /etc/certificates, but (1) don't name them either Default or the address certified (e.g., *.domain.net), and (2) make sure they are NOT entered in the keychain as well. One or the other, please.

2008-11-15

Note on using webdav idisk for experiment data

One of the problems I had before with setting up a script to manage the experimental scenario and data on a webdav idisk was that I hadn't stumbled across how to automatically mount & unmount the filesystem. It turns out that this is very easy.

First, create a directory to use as the mountpoint. For example, assuming you are in a writable directory, use something like this:

mkdir mnt

Next, use a command of this form:

/sbin/mount_webdav -s http://idisk.mac.com/groups.labname mnt

("groups.labname" should be replaced with the actual name of your idisk)

If the login info us not in your keychain, it will ask you for it. You might consider putting in the keychain for convenience. Note that any user (i.e., any RA who will access the database) must have access to the idisk.

Note that it is possible for a subdirectory to mounted directly with a command like this:

/sbin/mount_webdav -s http://idisk.mac.com/groups.labname/Databases/Thisdatabase mnt

However, in this case, a separate keychain entry will be needed to log in. It would normally be simpler to mount the root of the idisk and navigate its hierarchy programatically.

When complete, a simple "umount mnt" will be required.

Note that this method will work even if the idisk had already been mounted in the standard location or somewhere else.

About Me

My photo
Ignavis semper feriƦ sunt.