Mailbox naming issue

Question

I went to rename some folders within my mail box with all caps so they'd be easier/quicker to spot (I have things organized in higher level folders like work, personal, etc. and then have subfolders within each of those). Some renamed fine but some gave me an error that reads: Mail was unable to rename "~/Library/Mail/Mailboxes/WORK/photography". Those that give me that error make a copy of the folder & subfolders with the original folder being white and the new one (or the renamed copy) being blue like the other mail folders. I deleted one of the white versions but that caused all the subfolders in the new one to be deleted and that material can not be found anywhere. What am I doing wrong? I don't want to delete all the "white" originals and lose material in my "new renamed" folders but now I have two folders of all this stuff and my original goal of helping my organization is made worst. Is this making any sense? Thanks!

Answer 1

This appears to be a bug that I’ve seen reported here many times, but haven’t looked into it myself.
If the messages are not on the server and you don’t have a backup, you may try to salvage as many deleted .emlx files as possible with a data recovery tool such as Data Rescue II or FileSalvage. Of these, the only one I know for sure that can currently recover deleted .emlx files is FileSalvage. Stop using the computer right now if you want to try that, as anything you do with the computer may cause the deleted files to be overwritten.
What follows below is an explanation that may allow you to better understand what happened but won’t make the deleted messages to reappear...
<hr>
Take a look at the following article first for an explanation of what blue and white Mail folders are from a user’s point of view:
Blue and white Mail folders explained
Mail allows the same folder to behave as both a mailbox (i.e. contain messages of its own) and as a parent folder (i.e. contain other folders and mailboxes). Although such folders appear as a single folder in Mail, there is a different folder in the filesystem to support each aspect of this duality.
The mailbox functionality is provided by an .mbox or an .imapmbox folder in the filesystem, depending on whether the mailbox is stored locally on the computer or it’s a cached server-stored IMAP mailbox. Mail 2.x mailboxes should contain just an Info.plist file that may or may not be present and a Messages folder with an .emlx file for each message stored in that mailbox.
The parent folder functionality is provided by a folder without suffix in the filesystem. They shouldn't contain any messages of their own. For .emlx files to be recognized by Mail, they must be in a Messages folder within an .mbox or an .imapmbox folder.
If only the folder without suffix exists, Mail shows it as a white folder in the mailbox list (i.e. a folder that cannot contain messages of its own). If a folder with an .mbox or an .imapmbox suffix exists, it appears in Mail as a blue folder, regardless of whether a corresponding folder without the suffix exists as well. That is, for each blue folder in Mail there is a corresponding .mbox or .imapmbox folder and maybe also a folder without suffix in the filesystem, whereas for each white folder in Mail there can only be a folder without suffix in the filesystem.
Mail has some bugs & glitches when it comes to reorganizing mailboxes, more so if dual folders are involved. Things usually work better if each folder behaves as either a mailbox (blue) or as a parent folder (white), but not both (blue).
The problem you’ve experienced is probably also related to the fact that, in addition to being two actual folders in the filesystem associated with the single folder that Mail shows in the mailbox list, the filesystem that Mac OS X uses by default is case-preserving but case-insensitive, which means it preserves how file names are written, but treats file names that differ in capitalization only as if they were the same.
What appears to have happened is that one of the two folders in the filesystem initially associated with the folder that you renamed in Mail was successfully renamed while the other wasn’t, and that confused Mail about the duality of the folder and what to display where — note that the nested folders should have been displayed within the white folder, not within the blue one.
The thing is, Mail was clearly not working properly, so you shouldn’t have tried to “fix” the problem by deleting anything, at least not without making a backup first, or at the very least a copy of the ~/Library/Mail folder, which is very easy to do.
A workaround for this bug would be renaming the folder to something different first, then renaming it to what you want, i.e. avoid changing only the capitalization of the name — but of course that requires knowing that Mail has this bug in the first place...
<hr>
You may be able to fix what hasn’t been deleted yet by quitting Mail and manually renaming in the Finder one the folders of each pair, so that the capitalization of each pair of folders matches exactly again. Not sure whether it would be better to change the name of the folder that was successfully renamed back to the original name or the other way around — I’d try restoring the original name.
Be sure to make a backup copy of the ~/Library/Mail folder first, just in case something goes wrong while trying to solve the problem. You can do this in the Finder by dragging the Mail folder to the Desktop while holding the Option (Alt) key down, for example.
Note: For those not familiarized with the ~/ notation, it refers to the user’s home folder. That is, ~/Library is the Library folder within the user’s home folder, i.e. /Users/username/Library.