Unable to actually search by Folder Size in Finder

http://grandperspectiv.sourceforge.net/

 

http://developer.apple.com/Mac/library/documentation/Darwin/Reference/ManPages/man1/du.1.html

 

You can check "Calculate all sizes" in View Options, this will give you what you want

 

If you want to expand all subfolders hold down option key and click the expand arrow, then you can sort the whole folder by size.

You can do a automator action to view hidden folders/files.

 

Finder and the Search function are the worst parts of OSX. But what can you do :/ Pathfinder is even worse than Finder, bloated, sluggish crap.

 

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 +

 

All is working (as intended) now. Got rid of a SIGPIPE error [141] caused by (overloading?) head. And, using the more flexible/powerful sed (instead of head) also affords us an easy way to filter the target folder out of the results list. [note: the lone period '.' represents the current working directory. So either cd into the target first, or replace the '.' with the desired path.]

# handy one-liner:
find -x . -type d -exec du -smx {} \; |sort -binrs |sed -n 2,11p

# handy two-liner (copy & paste as one):
NUM=10; pwd -P; nice -n 20 find -x . -type d -exec \
du -smx {} \; |sort -binrs |sed -n "2,$((NUM+=1))p"

[^ change the NUM value from 10 to the desired length of list.]

Code:

[color="Blue"]cd ~/Library
find -x . -type d -exec du -smx {} \; |sort -binrs |sed -n 2,11p
[/color]
334	./Application Support
253	./iTunes
252	./iTunes/iPod Software Updates
135	./Application Support/MobileSync
135	./Application Support/MobileSync/Backup
115	./Application Support/MobileSync/Backup/2cff83743851d28dd...
106	./Application Support/Postbox
106	./Application Support/Postbox/Profiles
106	./Application Support/Postbox/Profiles/oyxdrf3y.default
 95	./Caches

Adding more sort options (especially -s) now produces the proper size progression (i.e., looks like it's walking down the hierarchy).

The command line i offer here isn't meant to represent a perfect solution to the original problem. Rather, it's more-or-less an archetypical end-product of a sincere first attempt.

 

Sorting by folder size.

Found this and it worked for me.


http://www.iclarified.com/entry/index.php?enid=14356

 

Technically, a folder is just a file that contains the names and pointers to other files (and folders). So a folder really has a very small size, it's the contents that take all the room!

For instance, my Documents folder contains 182,892,040 bytes of files (as determined from issuing the command "du -s Documents") yet the folder itself is mere 2006 bytes (as determined by issuing the command "ls -ld Documents"). Finding the size of the contents of a folder takes a long time because the size of every file contained within must be summed.

 

Mr. Cheeto is right

A little late to this party but it was one of the first Google results for "Can't check file size of Finder"

Mr. Cheeto is right. It is ridiculous, bordering on idiotic, that I can't ask the Finder to show me a list of folders over X amount of MB/GB in size. I appreciate the technical explanation below, but to be honest, some of it comes off as making excuses for Apple.

Seriously, with all of the technically wizardry available to Apple, doing a search on folder size is akin to asking your Mac to get up from your desk and mow your lawn?

I don't think being able to search for folder size is an unreasonable feature. Off to the feature request web page, I guess.

 

it used to be this way...

somewhere in the animal OS's they dropped the calculated folder size as part of EVERY search. if you have a panther or i believe leapard OS, when you search, the calculated folders sizes would eventually come up depending on the speed of your computer.

i am a photographer and i relied on this to compare folders to see if they are equal.

now it is a tedious process. what makes it even worse is that if you show view options in an open search window, the "calculate all sizes" check box is dimmed. it is a targeted maneuver by apple for speed or something.

if anyone has a workaround, i would appreciate it.

thanks
glenn campbell