Unable to actually search by Folder Size in Finder

MrCheeto

macrumors 68030
Original poster
Nov 2, 2008
2,967
0
What is the deal with friggin' Finder? I'm tired of Apple's baby-proofing by cutting this sort of functionality.

I am trying to find large folders on my hard drive. My Library is rather large, over two-gigs. Yet, if I do a search for Kind-Folder and Size-is greater than-1kb I get NOTHING! Why? Because the damn Finder is measuring the size of the folder itself, not its contents!!

So how, dear lawd, do I search for Folders that contain a certain amount of data? For instance, if I search for Size-is greater than-1gb my Library folder should show up, as the sum of its contents is greater than 1gb.

I'd settle for a Terminal command, but please tell me you can do this using Finder's search functions...
 

MrCheeto

macrumors 68030
Original poster
Nov 2, 2008
2,967
0
Thanks, but that isn't what I'm looking for. I've used it several times and it is handy for spotting large files and folders.

However, I'm wanting to just be able to search for individual folders on the system via Finder or Terminal.
 

MrCheeto

macrumors 68030
Original poster
Nov 2, 2008
2,967
0
OK, I don't see how these commands can differentiate from files and a complete folder's contents...seems I expect to much from such a pricey machine -.-'
 

petsk

macrumors 6502
Oct 13, 2009
362
235
You can check "Calculate all sizes" in View Options, this will give you what you want :)
 

MrCheeto

macrumors 68030
Original poster
Nov 2, 2008
2,967
0
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...
 

petsk

macrumors 6502
Oct 13, 2009
362
235
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.
 

MrCheeto

macrumors 68030
Original poster
Nov 2, 2008
2,967
0
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. This is the closest to a solution I have come so far.

Thanks.
 

petsk

macrumors 6502
Oct 13, 2009
362
235
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.
 

Hal Itosis

macrumors 6502a
Feb 20, 2010
900
4
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 +
 

Hal Itosis

macrumors 6502a
Feb 20, 2010
900
4
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.
 

talmy

macrumors 601
Oct 26, 2009
4,710
274
Oregon
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.
 

mattand

macrumors newbie
Jul 26, 2013
1
0
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.
 

gcphoto

macrumors newbie
Jan 22, 2015
1
0
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
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.