Unable to actually search by Folder Size in Finder

Discussion in 'macOS' started by MrCheeto, May 15, 2010.

  1. MrCheeto macrumors 68030

    MrCheeto

    Joined:
    Nov 2, 2008
    #1
    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...
     
  2. MrCheeto thread starter macrumors 68030

    MrCheeto

    Joined:
    Nov 2, 2008
    #3
    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.
     
  3. MrCheeto thread starter macrumors 68030

    MrCheeto

    Joined:
    Nov 2, 2008
    #5
    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 -.-'
     
  4. petsk macrumors 6502

    petsk

    Joined:
    Oct 13, 2009
    Location:
    Northern Europe
    #6
    You can check "Calculate all sizes" in View Options, this will give you what you want :)
     
  5. MrCheeto thread starter macrumors 68030

    MrCheeto

    Joined:
    Nov 2, 2008
    #7
    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...
     
  6. petsk macrumors 6502

    petsk

    Joined:
    Oct 13, 2009
    Location:
    Northern Europe
    #8
    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.
     
  7. MrCheeto thread starter macrumors 68030

    MrCheeto

    Joined:
    Nov 2, 2008
    #9
    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.
     
  8. petsk macrumors 6502

    petsk

    Joined:
    Oct 13, 2009
    Location:
    Northern Europe
    #10
    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.
     
  9. Hal Itosis macrumors 6502a

    Hal Itosis

    Joined:
    Feb 20, 2010
    #11
    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 +
     
  10. Hal Itosis macrumors 6502a

    Hal Itosis

    Joined:
    Feb 20, 2010
    #12
    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.
     
  11. neselain1 macrumors newbie

    Joined:
    May 19, 2013
  12. talmy macrumors 601

    talmy

    Joined:
    Oct 26, 2009
    Location:
    Oregon
    #14
    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.
     
  13. mattand macrumors newbie

    Joined:
    Jul 26, 2013
    #15
    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.
     
  14. gcphoto macrumors newbie

    Joined:
    Jan 22, 2015
    #16
    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
     

Share This Page