Very close! I would have to go through each folder and invisible folder and subfolder to check, though.
For the first time, my Mac has disappointed me...
While my hard drive grinds away the rest of the night, I'll at least find comfort in having SOME of that functionality I wanted.
While i'll never argue that Spotlight is all that it can be, you need to think about what you're asking for. There is no metadata for "size" associated with
folders. Folders don't "know" how large they are (in terms of disk usage). That value will always need to be calculated
on the fly by a utility of some sort. It's just not a job that Finder need preoccupy itself with constantly (by default), and —even if Spotlight had that feature for folders —it too would need to either be constantly updating that info for every single folder, or do the measuring when the search was run.
A dedicated utility is the logical solution, but then too: how do you imagine such a tool should behave?
Here's a one-line shell script example:
Code:
[COLOR="Blue"]find -x ~/Library -type d -exec du -ksx {} \; |sort -nru |head[/COLOR][SIZE="2"]
760380 /Users/halito/Library
338956 /Users/halito/Library/Application Support
258612 /Users/halito/Library/iTunes
257108 /Users/halito/Library/iTunes/iPod Software Updates
136044 /Users/halito/Library/Application Support/MobileSync
115268 /Users/halito/Library/Application Support/MobileSync/Backup/2cff83743851d28dd...
108264 /Users/halito/Library/Application Support/Postbox
108236 /Users/halito/Library/Application Support/Postbox/Profiles
91308 /Users/halito/Library/Caches
67428 /Users/halito/Library/Application Support/Postbox/Profiles/oyxdrf3y.default/Mail
[/SIZE]
There i searched for the top 10 largest "folders" in my user library. [Edit: note that the first version of my one-liner produced a memory error. This is a hefty task which is probably best handled by using a temp file to store intermediate results... and not expect it will always work within a single pipeline.]
Anyway, notice the 'nesting effect' in the results there? Of necessity, "Library" is the largest... and there are further redundancies along the line (e.g., Application Support), because each subsequent
parent is also part of the chain leading down to its
progeny.
At the end of the day, the feature which you expect should be there is not so trivial (both in terms of determining the answers and how "best" to display them). Also, there may be better ways to approach the same goal... perhaps finding the
largest files and/or folders with the
most files. After all, it is the
files which are really occupying the space —not folders.
§
Edit #2: hmm, interesting: using megabytes instead of kilobytes produces a slightly different outcome:
Code:
[COLOR="Blue"]find -x ~/Library -type d -exec du -msx {} \; |sort -nru |head[/COLOR][SIZE="2"]
743 /Users/halito/Library
332 /Users/halito/Library/Application Support
253 /Users/halito/Library/iTunes
252 /Users/halito/Library/iTunes/iPod Software Updates
133 /Users/halito/Library/Application Support/MobileSync
113 /Users/halito/Library/Application Support/MobileSync/Backup/2cff83743851d28dd...
106 /Users/halito/Library/Application Support/Postbox
90 /Users/halito/Library/Caches
66 /Users/halito/Library/Application Support/Postbox/Profiles/oyxdrf3y.default/Mail
48 /Users/halito/Library/Application Support/Pixadex[/SIZE]
For some reason, the "megs" run dropped that lone' 'Profiles' folder path. ::shrug::
--
^ EDIT #3: OBS: vastly improved accuracy and efficiency by using the -s option with du ^
btw... to see the original memory error, change the
\; to a
+ 
