Thursday, July 19, 2012

OS X Limitations: working around deletion of large numbers of files (time machine image)

I've run into problems like this, when I was unable to delete an OS X sparsebundle image on a Time Capsule.

I think I was able to use rm -r, but in some cases event that might not work. This Mac OS X hints discussion has several fixes: Script to delete huge sparsebundle images.

They include:
  • AppleScript invocation of rm -rv
  • unix commands including use of bands, xargs, head, find and so on.
The article includes related references

Monday, July 16, 2012

Fixing Outlook's Ctrl-D usability bug - with AutoHotkey

The letter S is next to the letter D - on my keyboard anyway.

That means when my lifelong q10sec Ctrl-S twitch hits, there's a 1/200 chance I hit Ctrl-D instead.

In Outlook Ctrl-S saves an email, but Ctrl-D deletes it - without warning. In the midst of my work my email vanishes.

This is annoying, but I usually catch it. I make a trip to the Deleted Items folder and drag the email back to Drafts. The other day, however, I was multitasking and didn't notice I'd deleted my email. It wasn't in the UI, it wasn't in Drafts, I probably assumed I'd sent it. Later I emptied my Deleted Items folder (because, by default, Microsoft's slightly daft Search tool includes Outlook Deleted Items, I keep that folder empty).

The email was gone. Minor panic ensued the next day. Fortunately I realized the email was lost, so I responded with an apology rather than being obnoxious.

I resolved to fix the bug. I found very little on the web, really just this one unanswered question: Ctrl-D del adjacent to Ctrl-S save. Either this afflicts very few people, or most don't realize what's happening.

So I asked on our corporate social network (Yammer) and a colleague gave me the answer. He wrote me an AutoHotkey macro that swallows the Ctrl-D key when Outlook is running.
;-------------------------------------------------------------------------------------
#ifwinactive ahk_class rctrl_renwnd32
^d::
return
It works!

Since I grew up on TSRs (if you don't know what that means then you are blessed in more ways than one) so I try to avoid system hacks like this, but Outlook's Ctrl-D bug has broken me. Since I've signed up, I now need to find other ways to use this utility...

Sunday, July 08, 2012

Pinboard and IFTTT - blog, task, share

Despite concerns about too many moving parts, I'm still using Reeder, Pinboard and IFTTT as my core information process workflow. I just added two more IFTT actions based on single character Pinboard tags. The current set is:

I enter the one letter space separated tags when I share to Pinboard from Reeder.app for iOS and OS X, or from Google Reader. Many posts have two or three tags.

Saturday, July 07, 2012

Password security: what if your desktop were stolen?

For various reasons, in addition to using 1Password (always encrypted), I keep a comprehensive set of family user credentials in a FileMaker database that began life over 15 years ago.

I need it to be accessible to Emily or my estate, particularly if I'm dead or incapacitated. I don't like making it too accessible though; recently a neighbors home was vandalized and some computers were taken. Losing hardware is always a problem, even if you have homeowner's insurance and good backups [1], but losing an unencrypted comprehensive password file is a bigger problem.

On the other hand, I don't need to defend against the NSA. The chances is low that anyone stealing my Mac would even bother to Google ways to browse the file system, or would know how to use FileMaker. It's even less likely that they'd scrape deleted or cache data. I just need need decent security.

Whole disk encryption would be more than decent [4], but I'm running Snowie [2] on the main machine. So I do that just on my MacBook Air. Instead this is what I do for the password file and for similar data:

  • Used Disk Utility to create a 500 MB 256bit encrypted sparseimage in Users/Shared and moved my files to it. These images ignore permissions by default, that's what I want.
  • I set permissions on both the sparseimage file and the mounted disk image to give r/w to Emily and I and nothing to anyone else. (You can't set permissions for the mounted image on the sidebar, you have to navigate the Finder to view the mount)
  • In both of our user accounts I mounted the image and allowed OS X to store the password in the user keychain (so anyone knowing our login pw can get it).
  • In both of our user accounts I added the image to the User Accounts login items.
With these settings every user can see a folder called 'confidential' (hint) but only Emily and I can open it.
 
It's just enough security so that if our home server were stolen I'd be able to revise our passwords over days rather than hours. [3]
 
-fn-

[1] I'm a believer in using two relatively unrelated techniques to do at least daily backup. For me thats Carbon Copy Cloner and Time Capsule/Time Machine with offsite rotation of 3 disks containing clones of varying age.

[2] Not only is Lion a memory/perfomance slug, it's also tied to iCloud -- which has been a bit of a disaster for me. I'm hoping to skip to Mountain Lion; maybe I'll get some features to go with the bloatware and the iCloud malware.

[3] The way I configure CCC deleted files are kept in archives. So after moving the database to the disk image I deleted it on CCC. That's not too bad a risk however because my clones are stored on an encrypted image (for offsite backup). So even if they take my backup disk they won't get much of benefit. If thieves took my Time Capsule I'd be in trouble with copies of the unencrypted file. So I opened TM and told it to delete ALL backups of the file (made me nervous to do that!). So I feel relatively covered, at least to the level of a typical burglar/vandal [4]  But wouldn't Time Machine backup the data to an unencrypted store anyway? Maybe a disk image is a better idea?

Update 7/18/2012: There's an odd permissions bug with creating documents on the shared image that limits this somewhat. Regardless of permissions on either the disk image or the mounted disk, whichever user mounts the image first has the "most" access. That is both users can open and edit existing documents/files, but only the first user to mount the image can create new documents. The second user gets this error message:

The operation can't be completed because you don't have permission to access some of the items.

This happens even though the image is configured to ignore permissions with both journaled and non-journaled MacOS formatted images and with sparseimage and standard image.

The workaround, paradoxically, is to turn off "ignore permissions" for the mounted image. With permissions enabled both users can read and write to the mounted image.

 

Thursday, July 05, 2012

Don't try converting a MacBook Core Duo to Lion

We converted our 2006 MacBook Core 2 Duo dual USB to Lion a few weeks ago.

Don't bother; the MacBook isn't up to it. It's too slow.

I suspect more memory or an SSD drive would help, but, really, six years is a long time for a laptop.

I think we're due for a new machine. When we get one I'll wipe this machine and revert it to Snow Leopard. That would mean no more iCloud, which is, at this point, a feature.

Incidentally, it has the flaking plastic border problem that's common with older plastic MacBooks. It started doing it four years ago and has been stable since; we use scotch tape to close the gaps. A friend tells me Apple will replace the broken plastic for free, even on quite old devices. The hassle isn't worth it for us, but it would be nice if that were true.

The Outlook 2007 blocked sender list import file function is flaky: how to fix it.

This summary is not available. Please click here to view the post.

Wednesday, July 04, 2012

Hotel iCloud

"… Welcome to the Hotel California
Such a lovely place (Such a lovely place)
Such a lovely face
Plenty of room at the Hotel California

"We are programmed to receive.
You can check-out any time you like,
But you can never leave…"

Eagles, Hotel California

I'm in recovery from a tedious multi-update post on my failed iCloud transition, and still digesting all I've learned. I'd like to pass on one conclusion.

iCloud really is different from MobileMe. 

MobileMe was a peer-to-peer synchronization service. My data lived on my machines, as well as on MobileMe.

iCloud is a server solution with local caching. The data moves to iCloud, it is no longer On My Mac.

Yes, I know it seems to be in the usual AddressBook folder, but as I discovered the real source of truth is remote. When there is a clash of opinions on the state of data, iCloud wins. If your data goes bad, you need to fix things on iCloud. Good luck with that.

Perhaps even more importantly, this is a one way trip. Yes, if you know the ins and outs you can copy Contacts back to your Mac and remove them from iCloud. You cannot, however, get your Group relationships back. That data has checked into Hotel iCloud.

With iCloud, OS X Mail and Address Book/Contacts are much more like Google Mail/Contacts -- which also has an offline mode. Apple's data lock is stronger than ever, and I have a very bad feeling about the next version of iTunes.