Unable to delete messages - a Mail.app 3.0 bug

There's a bug (surprise!) that hits a few Mail.app users when they upgrade from OS X 10.4 to 10.5.

I just ran into it upgrading my mother's ultra-plain Mac Mini from 10.4.11 to 10.5.2 and then directly to 10.5.7.

I did an update in place, not an archive and install. I didn't run Mail until the machine was at 10.5.7 and had gone through a post-update "safe boot" cycle to clean out old caches and debris. So I was surprised to find a very significant bug!

When I tried to delete an email from Mail.app 3.0 I got this error message:

The destination mailbox “Deleted Messages ... " does not allow messages to be moved to it.

I found several posts on this topic, but they were all IMAP configurations. The associated fixes in those posts didn't work.

My mother's mail uses POP against her Gmail account, this 2008 post by "Davl" had the fix:

In finder I opened the folder containing the mailbox folders of my POP account. It was located at:

My User Home Folder --> Library --> Mail --> POP/account name --> additional POP folder

In this folder were the mailboxes folders with .mbox extensions.

• Deleted Messages --> empty
• Drafts.mbox --> Messages
• INBOX.mbox --> Messages
• Sent Messages.mbox --> Messages

Note my Deleted Messages doesn't have a .mbox extension like the others do...

This is what I found  in icon view. Clearly there's something wrong with Deleted Message!

Yech.

This is what I did after confirming my Gmail POP settings were correct.

• In Mail.app I saw some "child" trash items. I deleted those and emptied the Trash.
• I quite Mail.app and moved the "Deleted Messages" folder to the desktop
• I restarted Mail. app and then deleted a message. The Deleted Messages folder was recreated

This bug goes back over a year, so it's disappointing that even in 10.5.7 Apple hasn't fixed it.

OS X internet bridging is WEP only

My parents don't have a wireless LAN at the moment, so I turned on Mac OS X 10.5 Internet connection sharing on my mother's Mac Mini. This is a bridging connection; it links my wireless clients with the household wired cable modem connection.

It works pretty well in their house -- I can work with my laptop and iPhone as needed. If you want to do mail, etc though you either have to turn off the firewall on the Mini or mess with ports.

There's one oddity -- unchanged from 10.4. When you set up "connection sharing" (bridging) the only available encryption is WEP (!). This is slightly better than nothing, but not much better; it's now trivial to hack WEP encryption. WEP also a pain to configure on a PC.

So why just WEP? Seems out of place, esp in 10.5.

Update 5/29/09: It's not only old-fashioned, it's also flaky -- like a LOT of things in 10.5. I find I have to periodically toggle it off and on again on the Mac Mini to get it working.

OS X 10.5.7 has a wireless problem?

We're on the latest round of OS X (10.5.7) and Airport Extreme (old, flying saucer model) fixes and something's gone downhill

No real mention on Google, so it's probably something with our older setup (Airport Extreme saucer station, Airport Express WiFi extender, 802.11g/b).

What we see is my MacBook on awake from sleep takes a while to get a connection, then it loses it, then it gets a lower power connection (maybe one of the stations) then it gets a full power connection.

Not lethal, but very annoying.

Update 6/7/09: I think I've found the problem.

Blank an iMac display - instantly (Leopard only?)

For years I've wanted to be able to turn my iMac display off on demand. There's no on/off switch of course, that would hurt the vibe.

It's a common desire. I need my iMac running at night so it gets backed up, but I don't want the photo show ("screensaver") running all night. On the other hand, I do like to have it run when I'm around. Problem is, nobody knew how to do this two years ago.

The best solution I found then was one of the elegant "dockables", which have been recently revived and updated (get the whole set!). The screen off dockable was quite good, but it had a few drawbacks. It couldn't be activated when the screen was locked, but when activated it left the screen unlocked. That's a problem with my kids.

Tonight, on a whim, I looked for current solution, and found How to turn off the iMac display | eHow.com.

Control-Shift-Eject. Presto, the screen is dark. It even works on a locked screen running my slideshow. (Control-Eject brings up the shutdown menu.)

WTF?! Why couldn't I turn this up two years ago? It's trivial to discover today. Was it some secret addition to an OS release? Was it always there, but only discovered a year or two ago?

The answer appears to be Yes and No. It's new to 10.5 (Leopard) and it's never been officially documented by Apple.

It doesn't appear in this 2006 article on similar shortcuts and it doesn't work on my old 10.3.9 iBook. It really only gets mentioned after Leopard is out.

Sigh.

On the one hand, a great feature. On the other hand, would it kill Apple to document it? It doesn't appear on Apple's recently updated screen shortcut kb article.

For me it justifies almost 10% of Leopard's purchase price. Hell of a way to run a company!

Following the trail leads to some other obscure Mac tips:

• Ctrl-K and Ctrl-Y will cut and copy text -- independently of Cmd-X and Cmd-Y. A separate clipboard.
• Option - Command - Eject: sleep computer (I knew that one)
• Many obscure Leopard tips

See also: Command-Option-Control-8 for reading in a dark room.

Why are all my Windows 2003 server folders read-only with a gray checkbox?

In the midst of a Kafkaesque episode of IT torture, I realized that all of my Windows 2003 server folders on every drive had a grayed-out (greyed-out) checkbox in the read-only attribute. The value of the checkbox could not be changed. (That is, it appears that it can be cleared, but on review it's set again. This is true even if one requests that changes propagate down the tree.)

In theory this means that somewhere in the tree of child folders there exists a read-only folder.

Was this related to the mind-crumbling miseries of my past week of IT hell?

Probably not, but the truth is dark enough. Microsoft has a kb article on this. I've cleaned it up, the original is poorly written. Emphases mine ...

You cannot view or change the Read-only or the System attributes of folders in Windows Server 2003, in Windows XP, or in Windows Vista

... Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows ... you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.

The Read-only and System attributes are only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box.

As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders.

When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set.

... if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer than expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.

Let's walk backwards to appreciate the horror of what Microsoft did here.

Suppose you want to display NTFS metadata like a file's name or comments in an Explorer view. This is a handy way to do what, millennia ago, we did using things like PC Magazine's dirnotes.com utility. Well, it's easy to enter that data, but how does Windows know to display it.

Ahh, here's where the horror of the hack sets in.

The metadata directions are stored in Desktop.ini files for each folder. It would be slow, however, for Windows to check that file every time an Explorer view is to be shown. So Windows 2003 needs to know when to check.

Cue dramatic music.

Some poor benighted soul realized that Windows (95? 98? NT? 2000?) doesn't use the read-only attribute for much. So he (must have been) had a brilliant idea. He'd hijack that attribute, and use it as a way to tell Windows that it needed to check the Desktop.ini file.

We know how the play unfolds now. Once this data value had been used this way the meaning changed. The text says "read-only" but the meaning is "look at the desktop.ini file".

We call that semantic drift.

Of course there's no reason for an attribute that really means "look at desktop.ini" to change the UI for a parent folder attribute of the same name, but that was inherited from the original use of the folder "read-only" attribute. It's a hack side-effect.

Finally, since "read-only" now meant "look at desktop.ini" it had to be reserved for system use, so Windows Explorer can no longer change that attribute. Of course attrib. exe can still change it, but probably you don't want to -- you're really telling Windows then to "ignore desktop.ini".

The Horror, The Horror.

Ping.FM: a router for status updates ... with just one small problem.

There are some disadvantages to being a mid-western geek of a certain entropic state.

If something doesn't show up in my Feed stream, I don't hear of it from my peers.

Take Ping.FM - for example. It's not new, but a GR search shows none of my sources called it out (but they did mention it -- with the assumption that any reader would know what they meant).

I found mention of it in a corporate blog I track at work ...

lbenitez . Luis Benitez . Socialize Me 

"... Ping.fm allows users to update their status in the following services from any of the following clients...".

So Ping.fm will update my status on LinkedIn, Facebook and Twitter. Great! Just what I've been looking for.

Except ...

Ping.fm needs my username and password for each of these accounts.

Riiigggghhhht.

Ok, that's a FAIL.

Maybe that's why no-one I read is keen on Ping.FM.

I'll check back if they're able to implement on OpenID mutual authentication framework.

Update 9/14/10: A relevant xkcd comic.

Address book Google synchronization weirdness

Now this is really weird.

Here are the OS X Address Book "General Preferences" on my 10.5.7 MacBook (where I sync my iPhone):

And here are the same settings on my 10.5.6 iMac

Right. The 10.5.6 iMac has an option called "Synchronize with Google".

How the #$! did that get there? Why doesn't the MacBook have this option? (By the way, Google Apps Exchange Sync still doesn't work in 10.5.7).

Lifehacker has the answer. Turns out this is quite old (I even sort of remember reading about it):

Mac OS X Leopard only: Today's release of Mac OS 10.5.3 added a juicy little tidbit to Address Book: the ability to automatically sync your Google contacts. After you've run Software Update and gotten 10.5.3 (and restarted your Mac), hit up Address Book's Preferences pane. At the button of the General tab, check off the "Synchronize with Google" box to get started. Be sure to back up your address book before you sync, and see the FAQ for more info. Update: Several commenters rightly point out that this capability only exists for iPhone and iPod touch owners by default, which is quite possibly a crappier move than forcing Safari onto Windows users on Apple's part. Time to switch to Linux. Update #2: Only a few hours later, a workaround surfaces. Non-iPhone/iPod touch owners, here's how to enable Google Contact sync.

Alas, I read through the comments on the hack to enable Google Contact sync without an iPhone/iTouch and it sounds problematic.

Based on a similar story with Exchange Sync this feels like a side-effect of iPhone synchronization. It's obviously disappointing that none of this stuff improved with 10.5.7. I'll take a look at the Google sync, fortunately it's easy to restore contacts. I'll just make sure I turn off MobileMe sync before I experiment.