I'm trying to reduce my hard drive space used to prepare for a move to an SSD. I've got a wonderful application called DaisyDisk that allows me to visualize data segments on my hard drives.

I have three internal drives, and for the time being I'd just like to slim down the size of my startup disk, so I can move it to a smaller SSD.

By far the largest segment of my hard drive is a section under Macintosh HD/Users/joelglovier/library/Mail/V2/Mailboxes. This directory is over 75GB. You can see the visualization from DaisyDisk here: http://cl.ly/E7OJ

I found this directory before, when trying to slim down my hard drive, and simply deleted it's contents, then changed my settings in Mail.app to not archive attachments, thinking that would resolve the issue.

However, some months later this directory has again creeped up to a ginormous size.

Can anybody please help me understand what this directory is for, and how to permanently reduce it's size - via Mail.app settings, or whatever I need to change to stop it from becoming so huge.

Thank you!

Note: I'm on OSX Lion 10.7.3 using Mail.app ver 5.2.

EDIT: SO I dug through the files in the directory in question. There was one particular mailbox in /Library/Mail/V2/Mailboxes called "Recovered Messages (account name).mbox" which contained a very strange subdirectory structure of a single email duplicated thousands of times under different subdirectory structures. For example, there was a subdirectory in it that had /1, /2, /3, etc., and each one of those directories had /attachments and /messages. The /attachments on each had hundreds of subdirectories each containing this one same attachement from a particular email, and the /messages under each had hundreds of copies of the email all with different numerical file names. But the weird thing is ALL were from the same exact email.


Question: How do I count the number of different child id's belonging to a parent record?
Answer: There are various ways to solve this problem, but with a composite index on (album_id, artist_id) most DBMS will manage to use only this index (a full index scan) with the following query and thus be quite efficient:

SELECT album_id
FROM track
GROUP BY album_id
HAVING MIN(artist_id) &lt; MAX(artist_id) ;


If you also want the number of artists per album, you can add COUNT(DISTINCT artist_id) in the select list.



A less obfuscated alternative condition is to use (which could be less efficient than the above MIN &lt; MAX method):

HAVING COUNT(DISTINCT artist_id) &gt; 1 ;