Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Since upgrading to Mavericks, Finder sometimes hangs when I select a folder and am waiting for its contents to populate the window. This happens primarily in Open dialog boxes:

Finder spinning

It'll spin for about 15-30 seconds before showing the items in that folder. I can "Go to folder" and it'll usually show the contents immediately in that case. Why does it spin, and is there a way to make it faster? (It should be instant. I don't go to folders with thousands or even hundreds of items.)

Clarifications: These are just regular, local folders, usually in my home directory... not Remote Disc or network shares or anything fancy. It's an early 2013 Retina MBP, so it has a solid-state drive.

share|improve this question

8 Answers 8

There are a number of Apple Support Communities discussions regarding this, and a number of possible fixes given. To summarise in case one works for you:

  • Disable Finder App Nap

    This seems to fix it for almost everyone on ASC who had Finder working fine in 10.8 but now is 'broken' in 10.9.

    sudo defaults write com.apple.Finder NSAppSleepDisabled -bool YES
    

    …then log out and back in with 'Reopen windows when logging back in' disabled.

  • Clear Finder Caches

    Empty ~/Library/Caches/com.apple.finder and restart Finder.

    rm -r ~/Library/Caches/com.apple.finder/ && killall -HUP Finder
    
  • Reset Finder Preferences

    Related to above — delete both preference files used by Finder:

    rm ~/Library/Preferences/com.apple.finder.plist ~/Library/Preferences/com.apple/sidebarlists.plist
    
  • Reindex Spotlight

    sudo mdutil -E /
    
  • Change the 'Show Scroll Bars' setting

    It seems that it can be fixed by changing the scroll bar setting in System Preferences → General from When Scrolling to Always.

  • Repair Permissions

    Try repairing permissions in Disk Utility.

share|improve this answer
    
Unfortunately these didn't solve the problem for me. But I like that there's a lot you can do to try! –  Matt Jan 7 at 15:14
    
Disable Finder App Nap solved it for me! –  macki Jun 9 at 18:49

Your snapshot shows that the asynchronous progress indicator (throbber) is the portion of the sidebar to draw:

  • Connected servers
  • Bonjour discoverable services
  • Back to My Mac

You should be able to focus on the networking and isolate whether this is truly the action that is delaying your work or just an innocent bystander being the next thing to be drawn when the system is otherwise paused and delayed.

To troubleshoot this I would do the following:

  1. Run sysdiagnose from terminal if I can reproduce the issue and see if I could catch a process using CPU or otherwise behaving different than an sysdiagnose when the system is otherwise idle. Skip this step if you don't like looking at system logs and going into terminal. This step may be valuable if you want to report this as a bug - the system shouldn't hang in my opinion to paint network services and should unblock the operation and show network devices later should that be slow.
  2. Turn off all three items above in Finder preferences for the Sidebar.
  3. Sign out of Back to my Mac
  4. Disconnect from the network

Since there are several items this could be - hopefully you can narrow things down or comment if I missed a step or more information on the problem comes to light. Also, be sure you don't have any tools like Little Snitch or Network Link Conditioner as they would clearly exacerbate the rendering of the network sharing portion of the sidebar if misconfigured.

share|improve this answer
    
I'd advise the same culprit hunt but in the following order: 4. (is this a network related problem, and I feel it is :( ), 2., 3., 1. (this will the hardest to analyse right :( ). –  daniel Azuelos Jan 4 at 13:41
1  
I like to measure first, then intentionally change something and remeasure. I might not examine the logs in detail, but have them captured should the need arise. I agree disconnecting the network is a great triage step and just to try to identify something in step 1 as opposed to "do not continue unless you found something" :) –  bmike Jan 4 at 15:17
    
OK for step 1 first as a snapshot of a misbehaviour and a reference along the hunt. –  daniel Azuelos Jan 4 at 15:47
    
This is indeed a clever idea. But I experience this delay on local folders and when disconnected from networks, so I don't think it's a network problem. –  Matt Jan 7 at 15:26

I don't understand all the specific technical details, but this is apparently caused by ISPs that perform NXDOMAIN interception. Following that forum post, try running this in Terminal:

ping Backups.backupdb

If you don't get the following response:

ping: cannot resolve Backups.backupdb: Unknown host

...then your ISP is performing NXDOMAIN interception, which is causing the delay.

The procedure to disable the interception depends on your particular ISP. For instance, if you're using OpenDNS (which does interception by default), you can disable it in your account settings.


I was having this exact same problem on my machine, and I was using OpenDNS (but without an account, so I couldn't change the setting). I simply switched back to my ISP's (AT&T) default DNS – which apparently doesn't do interception, since I got the "correct" ping response above – and the problem immediately went away.

(I take no credit personally for this solution; I'm merely reporting it here for everyone else's benefit. It seems to be a very common issue with Mavericks).

share|improve this answer
    
No NXDOMAIN interception here, apparently. (Using Google's DNS.) Thanks for reporting it here! –  Matt Jan 9 at 14:18
    
Another piece of supporting evidence: after I made this change, the hangs completely stopped while on my home network, but reappear when I'm at work. I didn't have a chance to do the ping test when I was there, but clearly it's network related since it's the same machine in both places. –  daGUY Jan 13 at 2:49

Just seen this post on Tuaw.com how-to-fixing-the-filestatsagent-bug by Erica Sadun

Quote from tuaw.com post:

At times, your system may seem to be spinning its wheels. A peek into Activity Monitor (found in the Utilities subfolder of your Applications folder) can offer clues as to what's going on....

..As I discovered, some Mavericks users may find a FileStatsAgent process has been eating away at their CPU. If this happens to you, it's generally due to a corrupt file.

They then go on to explain about using the open files and ports option in Activity Monitor on the process to see which files may be causing the problem.

This may or may not be your problem..

share|improve this answer

Note: though answer has now completely changed, this is just a late edit. I hope someone will benefit from this anyway.

Found a workaround which actually works, finally, from OSXDaily. To summarize, disabling network share automounting does the trick (at least for my few macs I've got Mavericks installed).

To disable network share automounting, open up Terminal.app and type in the following commands.

macbook:~$ sudo sh -c "cp /etc/auto_master /etc/auto_master.OLD && perl -i -pe 's/(^\/net)/#\$1/' /etc/auto_master && automount -vc"

What this does (for those less knowledge with command line, Bourne Shell and such) is that it first makes a backup copy of file /etc/auto_master, then edits one line of it and finally signals automounter to re-read /etc/auto_master.

After this you will have to manually mount your network shares. More information in original OSXDaily article.

share|improve this answer
    
Good thought -- I was wondering if generating previews for the icons was causing part of the problem. Unfortunately, I still get intermittent slow Finder behavior within apps, even for directories with just a few items in them. –  Matt Nov 19 '13 at 19:19
    
I've experienced that too, but did get some help from the solution above. I've updated the answer as well to reflect the fact that it's far from 100% solution. –  Sami Laine Nov 20 '13 at 3:00

Is it on every drive you have? Because if it is the same bahviour on different hardware? (Behavioural difference between a USB thumb drive and internal disk)

Is the "ls" command equally slow in terminal or instant? (try terminal and cd and drag an example folder into terminal and hit enter. Then type "ls" to see how long it takes to list the folders contents.)

  • This could also be due to HFS+ corruption (run disk utility "verify disk" (not the permissions) and see if your (I guess your start up volume is affected) has issues. As it probably will, boot from recovery (hold down cmd+R on boot) and try to repair the disk with disk utility from there.
  • Last but not least have you tried setting up a new user account and trying to reproduce it in a new user account?

Sorry for the many questions but I'm not (hopefully yet) allowed to comment on questions.

share|improve this answer
    
Thanks for contributing. ls is always instant. Interestingly, though, "Verify Disk" on my startup disk yielded a few errors: "Incorrect number of file hard link" and "Volume bitmap needs minor repair for orphaned blocks" and "Invalid volume free block count (It should be 43437880 instead of 40702664)" -- everything else is good. I'll try a repair and see if that helps... –  Matt Jan 8 at 16:23
    
I did the repairs and haven't seen the problem since (but it hasn't been very long yet) -- either way, it's a good thing to do, and your questions probed deeper into my problem. The bounty is expiring in a few minutes, so I awarded it to you, also as a welcome to the community. With a little more time I should be able to choose a best answer (if there is one that fixes it; but maybe Apple should just get on it!). –  Matt Jan 9 at 14:21
    
Phooey, it's still happening. –  Matt Jan 9 at 15:24
    
@Matt do you see anything related to my Answer? –  markhunte Jan 9 at 15:30
    
ok, thank you very much! Did you try making a new user account and analyzing whether this problem appears in a new local user, too? –  Hug Jan 9 at 15:38

I've been having the same problem for a few weeks, trying every suggestion listed here and other forums but without success.... until tonight!

TL;DR: Run these 2 commands then reboot.

mv ${TMPDIR}/com.apple.IconServices{,-bad}
mv ${TMPDIR}/../C/com.apple.IconServices{,-bad}

Long Version:

The problem did not happen when I tried a newly created user account so it pointed to something with my profile. I removed all the Preferences and Caches from my Library folder but the problem remained.

After examining the system logs, I noticed the following 2 errors would often appear when viewing a folder in the Finder.

12/16/14 12:24:29.908 AM com.apple.IconServicesAgent[244]: main Failed to composit image for binding VariantBinding [0x2af] flags: 0x8 binding: FileInfoBinding [0x3bf] - extension: mov, UTI: com.apple.quicktime-movie, fileType: ????.
12/16/14 12:24:29.908 AM quicklookd[8215]: Warning: Cache image returned by the server has size range covering all valid image sizes. Binding: VariantBinding [0xa03] flags: 0x8 binding: FileInfoBinding [0x903] - extension: mov, UTI: com.apple.quicktime-movie, fileType: ???? request size:16 scale: 1

These are related to creating/loading icons for different file types. The Finder is hanging while attempting to draw the icons for the file listing so it made sense that it would lag if there were problems with the cache. Since the IconServicesAgent isn't an application the user interacts with, the cache/prefs are not saved in the typical ~/Library/ folder but in a special hidden location used for OS-level apps and daemons. Every user has a Cache and Temp folder in this location at /var/folders/. We just need to locate and rename the IconServicesAgent's files.

When a user account is created, the system generates a folder here for the user but named with 32 seemingly random characters. Since they are random, I can't give you an exact path but the TMPDIR environment variable can. (If you want to know, run the command echo $TMPDIR to get the path to your own Temp folder. It will be something like /var/folders/jc/vzc51tfn2jzbzqkr9j3g38gm0000gn/T/ but we don't really need it. The commands below will just use the variable directly)

Now rename the com.apple.IconServices folder in the T [temp] directory with this command.

mv ${TMPDIR}/com.apple.IconServices{,-bad}

Next we need to do the same in the Cache directory, which is in the same parent directory as the T directory. This command will do what you need.

mv ${TMPDIR}/../C/com.apple.IconServices{,-bad}

So now reboot your Mac and after you log back in, the Finder should be quick again.

share|improve this answer

I sometimes have a similar problem: Finder is completely unresponsive, i.e., all Finder windows are frozen, and they all show the spinning beach ball.

In that case, for me the only thing that helped was to open Activity Monitor, and kill Finder (i.e., relaunch) it a number of times. Sometimes, I had to relaunch it up to 5 times.

(So far I haven't been able to pinpoint the culprit. I did not have any network disks mounted.)

share|improve this answer

protected by Community Mar 22 at 16:43

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.