Reset Finder

Go to ~(yourHome)/Library/Preferences and trash these two files:
com.apple.finder.plist
com.apple.sidebarlists.plist

Then log out and back in again. Or restart.
(You will have to reset a few finder prefs the way you like them.)

Have you tried creating a new account and see how your Finder works in that User acct? (That will tell if your problem is systemwide or limited to your User acct.)



-mj
macjack@gmail.com

Message was edited by: macjack

macjack wrote:
Go to ~(yourHome)/Library/Preferences and trash these two files:
com.apple.finder.plist
com.apple.sidebarlists.plist

Then log out and back in again. Or restart.
(You will have to reset a few finder prefs the way you like them.)

That won't work. You have to force quit the Finder. If you don't and let it quit normally via a log out or restart, it will simply write the old plist back to disk. You can force quit the Finder in a couple ways, but the easiest is to Control-Option-Click on the Finder in the Dock and select Relaunch.

As for the sluggishness, it might not be the Finder's fault. Launch /Applications/Utilities/Activity Monitor.app, in the window that appears sort by the CPU column. When the Finder is behaving slowly, is there some process that is taking up a bunch of CPU (30% or more) for an extended period of time? If so, then that is the culprit.

Hope that helps...

macjack wrote:

It's interesting how many processes have changed in 10.5. launchd is now Finder's parent.
launchd is the parent of all applications in Leopard. Its the app that launches everything.

macjack wrote:
Your point about quitting Finder normally is well taken and easier than restart, if you know what you're doing. But to an average user, restart is a familiar action. Yes, you can write a simple AppleScript to quit Finder but it may not be so simple to a user who has never done scripting. You can also accomplish the same in Activity Monitor by quitting the process.

I mentioned the AppleScript above to make your testing easier. I wasn't suggesting it as a solution for users.

macjack wrote:
You obviously have a strong background in Unix, Linux or both. I only know some of the basics at the command line and when I'm there, I'd rather not be. Wasn't the GUI what made the Mac the Mac, in the first place?

Yes.

macjack wrote:
In most cases, I don't see any reason to bring users into Terminal (where the possibility exists of doing more harm than good) when they can accomplish what they need via GUI.

I completely agree. However, I think you misunderstood. As above, I'm recommending to Force Quit the Finder, not let it quit normally (by logging out or restarting or AppleScript). Force Quitting the Finder can be done in a few ways via the GUI. Via tha "Force Quit Applications" window (Command-Option-Esc) or by Control-Option-Clicking on the Finder icon in the Dock and selecting "Relaunch".

Again, users should Force Quit the Finder. This is the method I have been recommending and what the Finder team also recommends (which is where I heard of this method in the first place).

I just moved aside my finder.plist, logged out and back in, then opened the old and the new finder.plist and they were identical. Test for yourself. In Terminal type:

mv ~/Library/Preferences/com.apple.finder.plist ~/Desktop/com.apple.finder.plist

Then log out and back in again and then double click ~/Library/Preferences/com.apple.finder.plist and double click on ~/Desktop/com.apple.finder.plist. They should both open in Property List Editor. Visually compare the two. Notice how they are identical? Now do this in Terminal:

rm ~/Library/Preferences/com.apple.finder.plist
killall Finder

Then double click on the new ~/Library/Preferences/com.apple.finder.plist. It too should open in Property List Editor. Compare it to ~/Desktop/com.apple.finder.plist. Notice how they are different?

As I stated before, your way just writes the old plist that the Finder had in memory back to disk. My way puts a fresh, default version of the plist on disk.

macjack wrote:
That's because your Finder.plist was not corrupted.

That makes no sense. What I did proved that the finder plist that is stored in memory is written back out to disk when the Finder quits normally. If the plist on disk was corrupt, then the plist stored in memory would also be corrupt (which is why the Finder behaves wierd when the plist is corrupt). When the finder launches, like most apps, its entire plist file is read into memory and isn't written back out to disk until the Finder is quit (log out/shutdown/restart) or a change is made to the in-memory plist (but isn't actually written to disk in this case until about a minute or so after the change was made. Probably for performance reasons).

Another method to prove this is to change the "Arrange By" setting on your Desktop. Then command-option-click on the Finder in the Dock and select Relaunch. When the Finder comes back up, the Desktop is back to your old "Arrange By" setting. If you change the "Arrange By" setting again, but this time log out and back in again, you'll notice that the setting stuck.

macjack wrote:
Try writing a bad instruction in your plist first.

For s**ts and giggles I tried this. I opened finder.plist in Property List Editor and changed DesktopViewOptions->IconViewOptions->ArrangeBy from 'kind' to 'blah'. I then force quit the Finder and when it came back up I noticed the Desktop was "Arrange By: Name". Anyway, I then moved the "corrupt" plist aside and quit the Finder. When the Finder came back up, I opened com.apple.finder.plist again and low and behold, the DesktopViewOptions->IconViewOptions->ArrangeBy was still 'blah'. Now, I then moved that finder.plist aside, force quit the Finder, when the Finder came back up I opened up finder.plist. To my "surprise" (can you read the sarcasm), the contents of the plist were at their defaults.

Any other tests you'd like me to run?

btw, you can get around the logout/login thing by sending the Finder a quit apple event (which is what its sent when you logout/restart/shutdown). Launch /Applications/AppleScript/Script Editor.app. In the window that appears, type

+tell app "Finder" to quit+

Click the Compile button and then the Run button. The finder will quit itself and won't relaunch (this is normal/correct) until you click on it's icon in the Dock.

Message was edited by: petrock

Check to make sure there are no other processes in progress, such as Spotlight indexing or Time Machine backup. If either are in progress, allow them to finish.

Do you have any third-party login items (System Prefs, Accounts) which may be slowing things down.

Do a "Safe Boot." Restart and immediately press and hold Shift until you see login screen with "Safe Boot" in red. Allow startup to finish, then restart normally.

Reset PRAM. Restart and before startup chime press and hold Apple-Option-P-R keys and keep holding those keys down until you hear startup chime three times, then release.

Repair permissions from with Disk Utility.

macjack wrote:

petrock wrote:
What I'm saying about resetting Finder prefs isn't some kind of ideology, its proven fact.

Is it?

Yes, try the tests I posted above.

I've proven above that allowing the Finder to quit normally (due to logging out and back in or restarting) will not produce a new/fresh .plist file and instead will write the old one back out to disk.

I have also proven that force quitting the Finder will, in all cases, produce a new/fresh .plist file.

While logout/login/restart method has worked for some users (probably due to the reasons I described above and below), there have been a bunch that it has not worked for until they tried force quitting the Finder.

macjack wrote:
OK, let's try something less trivial. Here is the test I ran. I edited my finder.plist by deleting the entire first half of the file. Then, deleted the plist and restarted. I knew it was correct as soon as my desktop populated with all my drives on it. I never keep them there and it is default behavior.

An inspection of my finder.plist file shows that indeed a fresh plist was written. Try it yourself.

Yeah, I did try it and a new/fresh com.apple.finder.plist was created. Then I did the same thing to one of the apps I've written and checked out what was actually happening in the code.

The reason a new .plist is created is because CFPreferences (the component under which almost all apps get/set/setup their .plists with) tries to load the .plist file in order to hand it off to the app but it fails because the .plist file is too corrupted (i.e. its missing its XML header data due to deleting the top half of the .plist file) and passes NULL back to the application instead of the file data/path. This is an indication to the app that there is no .plist file so it will use its default settings and CFPreferences will immediately write those settings back out to disk to blow away the corrupt/bogus/non-existent .plist file.

So, in short, your test doesn't prove anything other then that there is at least a small amount of error checking on the part of CFPreferences to see if the .plist file is valid before sending it to the application. If the .plist file is only mildly corrupted (i.e. only a couple entries missing or malformed, but the XML formatting is still correct for example) CFPreferences will not notice and send the file to the app and the app will try to use it resulting in weird behavior. In doing so, when the app is quit it will write that same bogus .plist back out to disk as I've shown in the tests from previous posts above (see my post above from Jan 31, 2008 2:23 AM for example).

So I'll say it again, causing the Finder to quit normally causes the same bogus .plist file to be written to disk after you delete its .plist file. Force quitting it causes a new/fresh .plist to be generated every time. No chance of bogus info being read in to the Finder etc. Plus it has the added bonus of being alot easier/quicker to force quit the Finder then it is to log out/in or restart.

macjack wrote:

petrock wrote:
Any other tests you'd like me to run?

Yes, just Google "Finder Preferences" and see what's there...

Yes, and that produces results of people saying to force quit and logout/login. Proves nothing. If your talking about the XLab web site, I wouldn't consider that to be a complete source of information. Although it does have some useful tid-bits, It is wrong on a couple of things too (I haven't read every article), not just the resetting of Finder prefs. It also screws up the Terminal method to empty the trash (it only works if the problem file/folder is in ~/.Trash, not if it is on any of the per-volume/per-user trashes).

What I'm saying about resetting Finder prefs isn't some kind of ideology, its proven fact. Actually doing the steps I described above proves my point. Logout/login doesn't produce a new .plist file. It just writes the old one back out to disk. You have to force quit the Finder after blowing away the old .plist to get a fresh/new/uncorrupted plist file written to disk. Plain and simple.

I did find this little gem via Google though: http://www.youtube.com/watch?v=pCpP5cTb5es

🙂

Perhaps, instead of Googling for Finder preferences, you should just search my posts here in AD for Finder & Desktop in 10.4 & 10.5. I've solved customers Finder problems again, and again, by deleting the preferences via log out log in or restart.

petrock wrote:
What I'm saying about resetting Finder prefs isn't some kind of ideology, its proven fact.

Is it?

OK, let's try something less trivial. Here is the test I ran. I edited my finder.plist by deleting the entire first half of the file. Then, deleted the plist and restarted. I knew it was correct as soon as my desktop populated with all my drives on it. I never keep them there and it is default behavior.

An inspection of my finder.plist file shows that indeed a fresh plist was written. Try it yourself.



-mj
macjack@gmail.com

Message was edited by: macjack

Hello petrock!

I had a busy weekend but I did have the time to do some testing. Finding new and different ways to hose the Finder;-)

In some but not all instances, logout/in did rebuild a corrupt plist. This does seem to depend upon the amount of corruption. In all instances, a restart after deleting the .plist, built a fresh plist file. This includes removing non-corrupted finder.plists. It's interesting how many processes have changed in 10.5. launchd is now Finder's parent.

Your point about quitting Finder normally is well taken and easier than restart, if you know what you're doing. But to an average user, restart is a familiar action. Yes, you can write a simple AppleScript to quit Finder but it may not be so simple to a user who has never done scripting. You can also accomplish the same in Activity Monitor by quitting the process.

You obviously have a strong background in Unix, Linux or both. I only know some of the basics at the command line and when I'm there, I'd rather not be. Wasn't the GUI what made the Mac the Mac, in the first place?

In most cases, I don't see any reason to bring users into Terminal (where the possibility exists of doing more harm than good) when they can accomplish what they need via GUI.



-mj
macjack@gmail.com

Thank you petrock, but it does work. I've used that hundreds of times for corruption in the plist. Perhaps you are thinking of the ds_store?

I also realize that the OP's issue may not be Finder prefs but because it's simple to accomplish, I asked him to try that first.



-mj
macjack@gmail.com

petrock wrote:
I just moved aside my finder.plist, logged out and back in, then opened the old and the new finder.plist and they were identical.

That's because your Finder.plist was not corrupted. Try writing a bad instruction in your plist first.



-mj
macjack@gmail.com

petrock wrote:
That makes no sense.

Why thank you, sir 😉
I've never done that by force quitting, only with restart or log out/in.

petrock wrote:
Any other tests you'd like me to run?

Yes, just Google "Finder Preferences" and see what's there...



-mj
macjack@gmail.com