recover outlook smart folders

got some really cool "smart folders" in outlook?

but outlook is crashing and even a rebuild didn't fix it?

so you just created an entirely fresh identity, which fixed the crashing (finally) - but you really don't want to have to try to remember how all those smart folders were built?

try this:

• outlook stuff is stored here: ~/Documents/Microsoft User Data/Office 2011 Identities/
• within that, there's: Main Identity/Data Records/Saved Searches/
• yep; smart folders are in there
• move the "Office 2011 Identities" dir/folder somewhere for safe-keeping
• fire up outlook again, enter your account info & let it start downloading stuff
• it may help to quit here; the rebuild below may take less time
• it may help to run "Microsoft Database Utility" & let it kill the daemon (then cancel the rebuild)
• copy the "Saved Searches" dir from your saved copy, over the fresh copy
• run "Microsoft Database Utility", do a rebuild, and let it complete (this appears required)

after i did this, the next time i opened outlook, my smart folders were there; hope this works for you

(now i just have to wait for spotlight to finish indexing the rebuild :/ to confirm that they actually work - though at least the definitions are visible now)

notes:

• geez; a whole lot of mail showed up in different places; lots of cleanup needed :/
• i copied my own smart folders; might also work for copying to other identities
• i'm on outlook 2011, on os x 10.10 (yosemite); may or may not apply to others
• i've got the common config of a single "identity"; this procedure resets _all_ idenities

iOS fast-forwards through all tracks & doesn't play any

Strange to hear / watch this happen:

Hit "Play" and nothing comes through the headphones (or speakers) at all; check the display and it's just zooming through all the tracks, spending less than a second before going to the next, over and over.

Mucked about for awhile and then came up with a theory:

It's due to the "Sound Check" feature, which I had just turned back on - and it now has to scan every single track to know what to do before it plays any.

Great background here: http://productionadvice.co.uk/sound-check-album-mode/

Sure enough, as soon as I let it go through all of them, it was able to play.

And then I turned "Sound Check" back off. :)

Has anyone seen some connection instability with the GlobalProtect VPN client (v1.2.2-14), on OS X 10.9 (Mavericks)?

Strangely, I see frequents drops of my entire WiFi connection (to an AirPort base station that's been solid before now) including to local (non-VPN'd) nodes as soon as I initiate the VPN connection (which also has been very solid before now).

Any clues?

FileVault2 (FDE) trvia

Interesting...

I configured my Mac to require me to enter the boot volume's FileVault2 passphrase before login; no automatic retrieval using an account's (less secure) login password.

This worked great, then at some point later, I added a second "Standard" account (for my Grandmother's iPad :) and the next time I booted (it's not that often; thanks for making a really stable OS, Apple) I noticed that this account was able to log in directly.

Hmm; somehow when the account was created, it glommed on to the FileVault2 passphrase - not nice.

System Preferences gave me no way to turn this off; interesting-er. Neither "Users & Groups" nor "Security" was any help; "Security" didn't even have this account listed via the "Enable Users..." button (toward the bottom).

To the Intertubes!

Here's an interesting article from IACR (International Association for Cryptologic Research) with lots of background: Infiltrate the Vault: Security Analysis and Decryption of Lion Full Disk Encryption. It didn't help solve this problem, though it was a useful read; thanks, IACR.

And the jackpot, at Krypted.com: Encrypting Volumes in OS X Mountain Lion is how I found out about the "fdesetup" command. (That's "fde" as in "full disk encryption".)

(BTW: After disabling this new account (with "fdesetup remove"), I opened the "Security" preference pane and it is now listed (as disabled) where it previously wasn't shown at all.)

[2015/03/20 update: If the output of "fdesetup list" is empty, no users have the capability, and it's required (as desired) to enter the disk password before login.]

DuckDuckGo Action for QuickSilver

A quick & dirty Applescript for a QuickSilver Action, to quickly do a web search with DuckDuckGo (AKA DDG), in the default browser:

using terms from application "Quicksilver"
 on process text ThisClipping
  tell application "Finder" to open location "http://duckduckgo.com/?q=" & ThisClipping
 end process text
end using terms from

Save the above as something like DDG.scpt, into "~/Library/Application Support/Quicksilver/Actions"; to make it your default, drag it above other Actions - such as "Search with Google".

Now:

• Fire up QuickSilver as you normally would (ex: command-space).
• Type a dot (if required) for free-form text entry.
• Enter your query & press Return; done.

Any suggestions for improvement are most welcome!

(I miss Searchling, however this is pretty close!)

Quick Look should display Spotlight comments as "alt text"

A modest suggestion for Apple's OS X:

When hovering over a "Quick Look" display, Spotlight comments should be displayed just like "alt text" in a browser window.

Lion: Hardware Growler crashes

For anyone using Lion and Hardware Growler (part of the excellent Growl package), you may have noticed that it crashes under some circumstances. (For example, see )

And if you're using it faceless, you may not even notice for awhile - say, til you realize you're waiting for a Growl that'll never come.

Fortunately, this is easy to slap a bandage over, with a simple bash script (all on one line):

while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done

(I know; a hard-coded path - you'll have to fix it if your path differs - if you know a better way, feel free post in the comments.)

I tried using a longer sleep, though the resource utilization was indistinguishable, so I left it at "1", which means it recovers almost instantly.

This can be "automated" even further: Into a text document, paste this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>WindowSettings</key>
<array>
<dict>
<key>ExecutionString</key>
<string>while true; do if [ $(ps jaxwwww|grep [H]ardwareGrowler|wc -l) = 0 ] ; then open /Applications/Growl-1.2.2/Extras/HardwareGrowler/HardwareGrowler.app; echo "$(date): launched one"; fi; sleep 1; done</string>
<key>Columns</key>
<string>44</string>
<key>Rows</key>
<string>15</string>
<key>WinLocULY</key>
<string>678</string>
<key>WinLocX</key>
<string>611</string>
<key>WinLocY</key>
<string>0</string>
</dict>
</array>
</dict>
</plist>


Save it as "something.term".

Double-click / launch the document and it opens Terminal.app for you. Add it to your Login Items, in the Users & Groups (nee Account) preference pane, and it's automatic.

(I believe the "WinLoc" keys are ignored in favor of an offset from the most recent Terminal window; pity - I'd like to place this at the same location on the screen each time. Though of course, Lion's "Auto Resume" handles this nicely too. :)

Lion: Use spacebar to scroll or page

In Lion, using the space bar to scroll doesn't work very well - or, sometimes, at all. Even if it just worked a moment ago, in the same page.

Here are a few workarounds I've discovered:

1) Click in the area you want to scroll (ex: within a web page) and then press space.

2) Press the down or up arrows and then press space.

3) This is weird: Press a shift key and then press space!

coreaudiod using too much cpu

Strange; my MacBook was performing fine, though I happened to notice that the CPU usage of the "coreaudiod" process was constant at about 10%.

There was plenty of idle, though it was enough of an irritant - especially since it had the highest cumulative CPU time of all processes - that I wanted to look into it.

(BTW: Nice concise man page for coreaudiod. :)

Interestingly, CPU usage dropped down under 2% as soon as I plugged in headphones, and jumped back up to 10% when I unplugged the headphones - very consistently, each time.

I profiled coreaudiod with Instruments (part of the Apple Developer Tools).

It was spending a lot of time in DspFuncHelper::process_IIR_xmm_LR(). The interesting symbols in the symbol stack under that: DspFuncEQ, IOAudioEngineUserClient, IOA_HWDevice, IOA_SingleDevice, IOA_Device, CAPThread.

I tried turning the iTunes EQ off. And then toggled it a few more times. No change. I tried quitting iTunes. Nothing I tried made a difference. I don't have any other audio apps (*) so I dropped it there.

There's some chatter online about it, though none seemed useful. (Mostly the standard voodoo of "Have you tried turning it off and on again?" (ref: The IT Crowd)

However there was one suggestion by a user named "bompi" in the Apple Discussions, to use launchctl to stop the process gracefully:

sudo launchctl stop com.apple.audio.coreaudiod

It automatically restarts - and even if you're listening to something at the time, there's only a very brief interruption.

I'd still like to figure out what happened, why, and how to prevent it, however this at least is a temporary fix.

*Correction: Obviously there are other apps that use audio, though no significant ones came to mind at the time. However, I do use Skype and that can obviously use audio - and I'd been conferencing about 12 hours earlier -- with some audio trouble (on my end only; the other side reported that it was fine). FWIW, it was Skype v5.0.0.7980 and I see that v5.0.0.7994 is available so I'll try that and see if that makes any difference...

Apple to drop Xserve

(For reference, Apple's Xserve Transition Guide.)

This has been written about by some good folks:

• A Eulogy for the Xserve: May It Rack in Peace (By Chuck Goolsbee, via TidBITS.)
  
• On the Xserve thing... (By John Welch (Bynkii), with a link to his full MacWorld article.)

They cover the downsides, however:

Apple's target market is the end user. Overwhelmingly.

As such, the server market has always been a straddle of the world of the end user and that of the IT department - though clearly there are still some markets where an Apple server is a great fit, such as organizations where there is no IT department.

However, the target for the Xserve in particular has moved - in large part, to the cloud (such as AWS (Amazon Web Services).

And the cloud is built, in large part, with commodity hardware - not Apple's business at all. The cloud is much less about serious high-quality equipment, as it is about lots of cheap stuff that is configured so that failure is fully expected; just toss it (while something else automatically takes over its load) and slot in another.

That's the hardware side, which is all Apple plans to drop (in January).

On to software:

Apple explicitly will continue to develop Mac OS X Server and will continue to develop some server configs based on its other CPUs; a Mac mini with Mac OS X Server is a very nice server - and fits Apple's target market much better. It's no Xserve - and many of us have no need for all the Xserve does -- nor any need to pay for it.

Though this transition will cause some pain for those of us who find great utility in the Xserve, this is a great move for Apple and aligns its resources where they fit best.

Oh - and by the way, here's a left-field idea:

Apple is in a far stronger position now, than when it first started selling Mac OS X Server. At which time, tightly tying it to Apple's hardware made great sense. And Apple's very firm policy (full price) on licensing even virtualized instances of Mac OS X Server, while rather painful, made a certain amount of sense too.

Now? The landscape is significantly different. The business case can be much more solidly made, that Apple could license Mac OS X Server on commodity hardware - including in the cloud.

A stretch, yes. But within reach.