Archive Utility doesn't work here either.
I doubt it's related to specific hardware, but just in case, its a MBP Mid 2009 running 10.8.2. Had the same problem under 10.8.1. Does not happen under Snow Leopard on the same system (keeping multi-boot for compatibility reasons).
Deleted com.apple.archiveutility.plist from ~/Library/Preferences just in case, but it doesn't seem to make any difference.
Make sure that the Archive Utility is not running.
- Go to the Apple Menu
- Select "Force Quit...". The "Force Quit Applications" dialog box will open.
- If "Archive Utility"...
- Is listed, then select it and press "Force Quit". Another box will open, again select "Force Quit".
- Is not listed, do nothing.
- Close the "Force Quit Applications" dialog box (click the red button, upper left corner of the dialog box).
Navigate through your folders and delete the file:
Tthis may not be required, but I do this whenever I trash a system-related ".plist" file to prevent the OS from quickly re-creating the file.
That should fix it.
It did for me.
I have the same problem on 10.8.2. Deleting preferences does not fix it for me. Neither did repair permissions / reboot. Other similar apps like flashmount have also stopped auto-quitting. I do not have default folder X.
see also this other thread: https://discussions.apple.com/thread/4139543?start=0&tstart=0
A little hair-pulling and persistence identified Typinator (5.3) as the culprit in my case. Quitting Typinator allowed Archive Utility to return to normal behavior; relaunching Typinator reproduced the problem. Ergonis has been notified. Good luck to all.
Thanks for posting this. More than a little hair-pulling and I never figured it out. Same here - Typinator running -> apps don't quit; Typinator not running -> apps quit.
Unfortunately, none of the above suggestions seem to solve the problem:
Archive Utility starts and never completes unarchiving, it just freezes and needs to be force quit.
This happens both on a MacBook Pro (Mid 2009) and on a Mac Pro (Early 2009), both running OS X 10.8.2. No extensions such as the abovementioned Typinator/Default Folder/etc are present on either system.
Deleting com.apple.archiveutility.plist from preferences did not improve things.
Repairing permissions and immediately rebooting may help for a little while, but Archive Utility stops responding again soon.
This problem remains unsolved.
Mitja, sorry to hear that the Typinator conflict doesn't apply in your case, but it does strongly suggest that the problem is caused by what used to be called "init conflicts," which in this case means a conflict between Archive Utility and some third-party app. I'd suggest that you disable your login items in groups to see if you can isolate which app might be conflicting in your case. This is how the old "init conflicts" could be resolved. So you can disable, say half of your login items, reboot, and give Archive Utility a test. If you still have the problem, reenable those ones and disable the other half. You should reboot, of course, each time you make these changes. If at some point Archive Utility behaves, you will have narrowed down the offending third-party app. A bit more narrowing down should identify which one is interfering with Archive Utility. All of this assumes that the incompatible app is hiding in your login items. If the problem is being caused by an app that isn't, the troubleshooting is harder, but the Typinator issue does strongly suggest that the problem is arising from an incompatibility with an app that is adversely affecting Archive Utility rather than, from, say, a but in OS X.
Hello Golabuk, I too remember the "good old" INIT conflitcs in Mac OS 9 and older.
But there are no INITs in Mac OS X : there are Kernel Extensions, Service Management-based login items, Launch Services, etc.
I was also considering whether a 3rd party application may conflict with Archive Utility. However, the same issue with Archive Utility freezing happens on a Mac Pro running 10.8.2 that is used for "clean room" testing and development, i.e. on the Mac Pro there is OS X 10.8.2 with Apple's Xcode development system, and no other app there that could cause the incompability.
Since the same issue does not happen on the same hardware booting from 10.6.8, it seems likely that this may be a bug introduced by 10.8.x.