Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

If MobileMe suddenly stops working on the Mac System
I have 2 iMacs and an iPhone all in sync via MobileMe. Out of the blue, one of the iMacs refused to sync. It let me sign in via Preferences » MobileMe; but the Mac was no longer registered and nothing would permit me to re-register the Mac.

All of the other devices were working fine.

Here's how I got it to work again:
  • First sign out from the affected Mac.
  • Then go into Keychain Access. In the list of Keys, seek out a Key called MobileMe Password which has the Cloud icon beside it. It's probably in the Login keychain. Right Click (Ctrl+Click) on this and delete it.
  • Now sign in to MobileMe via Preferences and all will be well. Click on Account and then Advanced and Register your Mac.
  • When you've done that, select items to Sync and when prompted choose Merge -- this is vital to preserve what's on your Mac.

[crarko adds: This sounds like a damaged Keychain, or something getting scrambled with the encryption. I've typically see this with Wi-Fi keys or email passwords getting messed up in the Keychain, and the solution was the same.]
  Post a comment  •  Comments (3)  
  • Currently 4.25 / 5
  You rated: 4 / 5 (4 votes cast)
 
[5,417 views]  View Printable Version
Boot to Windows partition quickly System
I wanted a quick way to boot once to Windows. Typically I reboot and hold the Option key to select an alternate startup disk. I've decided that I will upgrade the video card on my Mac Pro to an ATI 6870. Since there is currently no way to flash the card to EFI I will not be able to see the boot drive options when I boot holding down Option.

And I don't want to change the boot drive every time I want to boot to Windows. When I'm done with Windows I like to just reboot and leave knowing the rest will just happen.

I came up with this little script:
#! /bin/bash
diskutil list > /tmp/connecteddrives.txt
INPUT=/tmp/connecteddrives.txt
driveid1=$(grep Microsoft "${INPUT}" | awk '{print $8}')
echo $driveid1
sudo /usr/sbin/bless --device /dev/$driveid1 --setBoot --legacy --nextonly
rm /tmp/connecteddrives.txt
exit 0
You may need to change the awk '{print $8}' command if you have spaces in your Boot Camp volume name.

To find out if it will work simply type this into terminal:

diskutil list|grep Microsoft|awk '{print $8}'

If you get something along the lines of disk#s# it works. If not change the number 8 up or down by one till you find it. Then modify the script accordingly, make it executable and enjoy.

[crarko adds: I don't use Boot Camp, so I haven't tested this one.]
  Post a comment  •  Comments (14)  
  • Currently 3.50 / 5
  You rated: 2 / 5 (6 votes cast)
 
[9,352 views]  View Printable Version
Dashboard Doesn't Lock (Feature or Security Issue?) System
I have three external monitors hooked up to my MacBook Pro. One is connected via the Mini DisplayPort, and two are connected via the USB port using a Kensington USB to Display adapter.

When the OSX Dashboard is open, it opens on all three monitors. My computer is set to sleep after 10 minutes of inactivity, and a password is required to log back in.

I noticed that when the login box appears on the main monitor, the second and third monitor still show the OSX Dashboard! I can interact with the Dashboard (move/close widgets) even though my computer should be locked.

I was under the impression that when the computer is in the locked state, you would need a password to access any information or make any changes. For some reason, the Dashboard (on the second and third monitor) remains accessible even though the computer is 'locked.'

This would seem to be a security issue. However, it could be classified as a feature as it could be helpful to be able to leave the Dashboard up on an external monitor and allow people to use it without having to log in.

[crarko adds: I don't have a setup approximating this to test with. I would surmise that this is connected to the drivers for the USB Display Adapter, and that Kensington, Apple, or an intrepid 3rd-party developer could write a driver that would change this behavior. If someone else with this setup could confirm the behavior is repeatable, please post in the comments.]
  Post a comment  •  Comments (6)  
  • Currently 2.60 / 5
  You rated: 3 / 5 (5 votes cast)
 
[4,463 views]  View Printable Version
Removing compromised system root certificates System
This hint shows how to remove the Diginotar System Root certificate. You must be an administrator to take this action.

Open KeyChain Access, and select System Roots under Keychains. Type 'diginotar' in the search field on the upper right. When I did this only a single certificate was left in the list of certificates. Select that certificate and press the delete key. Confirm that you want to delete it, and expect to enter your password.

Note: I right clicked on this certificate and selected 'delete' a couple of times but that did nothing.

[crarko adds: This hint was actually submitted prior to the release of Apple Security Update 2011-005 for Lion and Snow Leopard. That update handles this issue for those versions of the OS, but there is no update for Leopard or earlier systems, so these still require manual fixing. For stronger measures than what is included in this hint, I refer you to this excellent article on the subject.]
  Post a comment  •  Comments (2)  
  • Currently 3.14 / 5
  You rated: 4 / 5 (7 votes cast)
 
[16,275 views]  View Printable Version
Bluetooth Menulet -- Create Diagnostics Report System
Works in 10.6 and 10.7. Requires a Mac with Bluetooth (probably built-in Bluetooth).

A follow up to the two-year-old hint 10.6: See new functions on various menu bar icons. If you Option-Click the Bluetooth Menulet, you get an option to 'Create Diagnostics Report on Desktop.'

I always assumed this was just the Bluetooth Diagnostics report, but when I clicked it, it created a ZIP on the Desktop: BluetoothReporter_DATE_TIME.zip.

This file is far more useful than I suspected. It contains:
  • kernel.log
  • PacketLoggerBluetoothTraceFile.pklg
  • system.log
  • system.log.0.bz2
  • SystemProfilerReport.spx
  • WebProcess_DATE_TIME_COMPUTERNAME.crash
This is all in one neat Zip file, in two clicks from the Desktop. It's worth it for the System Profiler Report, System Log and Crash Reports alone.

Perfect for sending to a Service Provider or engineer for diagnosis.

[crarko adds: This is really handy. I've used it myself to help in trying to debug an iOS app I was working on, that used Bluetooth within the Simulator.]
  Post a comment  •  Comments (4)  
  • Currently 4.13 / 5
  You rated: 5 / 5 (8 votes cast)
 
[4,419 views]  View Printable Version
Better management of OS X Services System
It's widely known that the OS X Services infrastructure was completely overhauled (and made significantly more useful) in Snow Leopard. What virtually no one seems to be aware of is that Apple released a 'Services Manager' tool as long ago as 2009, which offers significant advantages over using the built-in support in the Keyboard preference panel.

In Snow Leopard (and now in Lion), it's possible to create your own Services (using e.g. Automator), and it's also possible to disable or enable Services provided either by applications or the system itself, by going to the Keyboard Shortcuts tab of the Keyboard preference panel.

However, the Keyboard preference panel has a number of limitations when it comes to editing Services, and unfortunately these limitations add up to it being just about unusable in practice. For example, while you can activate or deactivate a particular Service, there's no way to specify whether that Service will only be available on the Services menu, or (much more usefully) on relevant contextual menus as well. OS X seems to decide which Services appear on contextual menus based on its own arcane rules.

Services are listed by name only in categories based on their function. There's no easy way to see whether a particular Service is offered by the system itself, a third party application, or (say) an Automator workflow in /Library/Services or ~/Library/Services.

Back in pre-10.6 days, when there was no officially supported way of editing Services, a free tool called Service Scrubber by Many Tricks Software could be used for this purpose. Due to the changes made to Services in Snow Leopard, Service Scrubber no longer works in 10.6+. I've often wished there were a modern replacement.

As it turns out, there is! A tool named Service Manager is provided by Apple itself, hidden away on its macosxautomation.com website. You can download it here, and you'll find it provides all the functionality mentioned above, and more. Services Manager was intended for use with Snow Leopard, but I have so far found no problems using it in Lion.

[crarko adds: Works the same in either Lion or Snow Leopard. This is a great little utility.

Note: since some people seem to be freaking out in the comments here is some referential information about Sal. He's pretty much the boss of Services.]
  Post a comment  •  Comments (17)  
  • Currently 4.21 / 5
  You rated: 5 / 5 (14 votes cast)
 
[18,628 views]  View Printable Version
A note on Database Events System
Database Events.app (one of the scriptable background apps that appeared in Tiger) is intended to give some basic access to the sqlite3 database system. It has been generally maligned as a not-too-useful app, and in fact I am one of the people who has maligned it that way. But while playing around with it today I discovered that it is actually much more powerful than anyone seems to realize. Thus, a quick hint to clue everyone in.

First, don't set your hopes too high: DE is not a full-featured SQL processor. There are no tables, no meta-structures, not even a built-in sorting system. The database DE makes is just a simple flat list of records with fields, much like single-page spreadsheet. So for instance, you build up a dataset like follows (this creates a database and populates it with random data):
tell application "Database Events"
  set db to make new database with properties {name:"tester", location:(path to desktop)}
  tell db
    repeat with i from 1 to 15
      set thisRec to make new record with properties {name:"Record " & i}
      tell thisRec
        -- A field called 'name' - e.g. name:"name" - is automatically linked of the 
        -- to the 'name' property of the record, above; doesn't matter which you set.
        make new field with properties {name:"first", value:(some item of {"alpha", "beta", "gamma"})}
        make new field with properties {name:"second", value:(some item of {1, 2, 3})}
        make new field with properties {name:"third", value:(some item of {"double-u", "ex", "why", "zee"})}
      end tell
    end repeat
    close saving yes -- this clears the database out of memory
  end tell
end tell
Run this and you'll see a file called 'tester.dbev' appear on your desktop. You can use this newly created database in the obvious ways, like so:
set db to (POSIX path of (path to desktop)) & "tester.dbev"
tell application "Database Events"
  tell database db
    --get the third record by index
    set a to name of record 3
    --get the value of field 'first' of every record
    set b to field "first"'s value of records
    -- set the value of field 'second' of the record "Record 11"
    set value of field "second" of record "Record 11" to "Boo"
  end tell
end tell
But what's not at all evident is that each search is itself an object that you can modify, search on, and otherwise work with. For example:
set db to (POSIX path of (path to desktop)) & "tester.dbev"
tell application "Database Events"
  set bill to database db
  tell database db
    -- set the value of field 'second' to 'hey' wherever third's value is 'why'
    tell (records whose field "third"'s value is "why")
      tell field "second" to set its value to "hey!"
    end tell
    -- set the value of field 'second' of any record whose name is "Record 11" (note the plural)
    set value of field "second" of records "Record 11" to "Boo"
    -- delete any record whose name contains '1'
    delete (records whose name contains "1")
    --get the name and the value of field 'second' where the value of field 'third' is 'ex'
    tell (records whose field "third"'s value is "ex")
      set c to {name, value of field "second"}
    end tell
    close saving yes
  end tell
end tell
So as you can see, once you get this trick of using compound objects Database Events becomes a reasonably powerful tool, at least for quick and simple databasing.

[crarko adds: The only other real reference I could find to Database Events.app is here. The application is found in System » Library » Core Services. The article referenced above gives more information about scripting Database Events.]
  Post a comment  •  Comments (4)  
  • Currently 3.43 / 5
  You rated: 2 / 5 (7 votes cast)
 
[5,180 views]  View Printable Version
Track changes made with the defaults command System
There are many hints that involve the use of the defaults command to change system settings. When trying to keep my Macs in sync (as well as setting up new ones), I have difficulty remembering which changes I've made. So after some work I was able to build a script that nicely tracks the changes I make to the system.

My requirements were to log any writes or deletes, showing both the old value and the new value to a log file in ~/Library/Logs/ where it is accessible to Console. (I use logger too but those messages get lost in the noise and are aged off). I wanted to leave any other defaults command (read, find, etc.) alone.

My first try was to write a function in my .bash_profile, which is loaded at every login and overrode the executable. That seemed fine until I realized that when using sudo defaults, it wasn't working. This is because sudo simply executes a command as different user without logging in and getting the benefit of profiles. It changes certain environment variables and drops all functions and aliases. So the most important changes of all were missed.

My solution was to create a script and place it in the path prior to /usr/bin/defaults. Thus when sudo calls the command without profiles, it runs the script instead of the binary (you could also do this with a link if the path is a problem).

I export a variable with the path to log file and define a log function that includes the date/time in my .bashrc so it's available to every bash shell invoked (login or not) under my username. You can easily just put these lines in the script itself, but it turns out to be convenient to be able to log anything at the terminal with the function, so I define it in ~/.bashrc:
export lf=${HOME}/Library/Logs/com.yyyy.log
function log() { echo "$(date "+%Y-%m-%d %H:%M:%S") bash $@" >> ${lf}; }
Here is the script 'defaults':
#!/bin/bash
# Defaults - a script to record important changes to the system
source ${HOME}/.bashrc
if [[ ! ${1} ]]; then
    echo "This is the script version of defaults.  Run /usr/bin/defaults to see help"
    exit 1
fi
if [[ (${1} == write) || (${1} == delete) ]]; then
    op=${1}; dom=${2}; key=${3}; shift; shift; shift; args="${@}"
    [[ (${op} == write) && ("${args}" == "") ]]  && args='""'
    log "${USER} executed defaults ${op} ${dom} ${key} ${args}"
    logger "${USER} executed defaults ${op} ${dom} ${key} ${args}"
    log "existing value: \"$(/usr/bin/defaults read ${dom} ${key})\""
    logger "existing value: \"$(/usr/bin/defaults read ${dom} ${key})\""
    /usr/bin/defaults ${op} ${dom} ${key} ${args}
    log "new value: \"$(/usr/bin/defaults read ${dom} ${key})\""
    logger "new value: \"$(/usr/bin/defaults read ${dom} ${key})\""
else
    /usr/bin/defaults $@
fi
Note that the single and double quotes are difficult to see but nonetheless important. Also note the usual complaints by defaults when changing a key that does not exist still apply -- it complains but does actually make the change.

[crarko adds: I haven't tested this one.]
  Post a comment  •  Comments (5)  
  • Currently 3.50 / 5
  You rated: 3 / 5 (8 votes cast)
 
[5,618 views]  View Printable Version
Always keep an application open System
If you have some app that you always want to keep open -- in my case it's Stickies and DragThing, which I use frequently -- it's easy to set up the computer to do that for you.

For example, to keep Stickies permanently open, remove Stickies from the login items for your account (if you've placed it there), quit Stickies, and then create the following plist file in the LaunchAgents folder of your home Library (~/Library/LaunchAgents) with the name user.launchkeep.stickies.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>user.launchkeep.stickies</string>
  <key>KeepAlive</key>
  <true/>
  <key>Program</key>
  <string>/Applications/Stickies.app/Contents/MacOS/Stickies</string>
</dict>
</plist>
Now load this launchd job by logging out of your account and logging back in or launch Terminal and enter:

launchctl load ~/Library/LaunchAgents/user.launchkeep.stickies.plist

Stickies will now effectively be un-removable -- any time it quits, crashes, or gets forced-quit it will pop right back up. If fact, in order to quit the app at any time other than logout or shutdown you'll need to disable the job; In Terminal type

launchctl remove user.launchkeep.stickies

Or you can set up a script that does that for you.

Note that you have to use the path to the inner executable, not the path to the app package - you can find this by right clicking on the app icon, choosing Show Package Contents, and navigating down to the MacOS folder where the main executable is stored. If you do something wrong, the general result will be that the app is not only kept alive, but in fact keeps launching every 10 seconds or so (launchd's throttle time-out), so that it keeps grabbing screen focus, which is very annoying. if that happens, just unload the plist, make sure it is correctly written and the app is quit, then load it again.

[crarko adds: I haven't tested this one.]
  Post a comment  •  Comments (22)  
  • Currently 3.44 / 5
  You rated: 1 / 5 (9 votes cast)
 
[23,842 views]  View Printable Version
Unfreeze when moving between spaces System
Sometimes when I move between spaces, the little animation freezes (doesn't fade away), and it blocks out all keyboard access. I can still move between spaces (though this usually doesn't unfreeze it), and use the mouse.

I used to fix this by quitting the Dock with Activity Monitor (which was annoying because I had to do the whole thing only with the mouse), but today I discovered that if I press the Dashboard key on my keyboard (it's F12 by default), it unfreezes it (and it doesn't even open dashboard).

[crarko adds: I haven't tested this one. Any ideas about why this should be the case?]
  Post a comment  •  Comments (26)  
  • Currently 4.25 / 5
  You rated: 3 / 5 (4 votes cast)
 
[5,023 views]  View Printable Version