Posted in Automation, Windows on 02/27/2009 06:00 pm by jmccune

My laptop at work is not automatically backed up, so I maintain a folder named “Warehouse” in My Documents that I used offline files to synchronize to our central file servers, which are backed up. Since the primary method of accessing offline files is through a mapped drive letter, I had performance issues with shortcuts and applications being accessed through the network.
I’ve since disabled offline files, installed the Microsoft SyncToy 2.0 [1] and configured a scheduled task to synchronize the Warehouse folder to the network file server and to a TrueCrypt encrypted disk image on portable, external storage.
This solution works quite well. If the encrypted disk image is not mounted, SyncToy doesn’t complain, and when I’m off the corporate network there aren’t any issues either.
In order to configure the task to run automatically, make sure to Run “C:Program FilesSyncToy 2.0SyncToyCmd.exe” -R
I have the task run after 10 minutes of idle time, which is perfect for my lunch break or whenever I step away from the computer. This also prevents lengthy sync processes from kicking off at log-in or log-out which I found annoying with Offline files.
Posted in Mac OS X, Shell on 11/27/2007 05:08 pm by jmccune
Here’s a quick script I cooked up to turn off the blinding light that is my iMac display when I go to bed at night.

Features:
- Runs great from Quicksilver.
- Talks to you. (May not be a feature.)
- Doesn’t require administrative rights.
#!/bin/bash
# Jeff McCune
export CURRENT_DELAY=$(pmset -g | grep displaysleep | awk '{print $2}')
# Charger or Battery Flag.
pmset -g | grep -q '^AC.*\*' && export MODE="-c" || export MODE="-b"
say "The display will shut off in about 90 seconds" &
# force allows this to work for non-admin users.
pmset force $MODE displaysleep 1
# Quicksilver blocks until script completion. Fork off the reset command.
bash -c 'sleep 120; pmset force $MODE displaysleep $CURRENT_DELAY' &
exit 0
Posted in Leopard, Mac OS X, System Administration on 11/14/2007 12:15 pm by jmccune
James Reynolds mentioned on the Mac Enterprise mailing list that /etc/rc.local scripting is no longer a viable option to execute scripts at boot time, before the loginwindow presents itself to the user.
In Mac OS X 10.4, I’ve relied heavily on /etc/rc.local to execute a number of management scripts, and /etc/rc.local has always irritated me as a solution because of the parallel nature of sub-systems coming online during the Mac OS X boot process. Note; I didn’t say “boot sequence.” For example, I have some pretty extensive code to simply detect if DNS resolution is working or not.
Now that loginwindow is started from launchd, we’re able to replace it with our own scripts, and ultimately call it when we’re finished. I have yet to try this as a replacement for my current system, but I’m hopeful there aren’t as many issues figuring out what’s available and what isn’t at boot time, now that many more processes are started form launchd.
I’ll report back with any problems I’m sure to encounter migrating my startup scripts to launchd in Leopard.