Archive Utility doesn't quit when finished in Mountain Lion

I'm seeing this, too. I have no idea what could be causing the problem. If you create a new account and try unzipping, does Archive Utility still hang?

Same problem here. A reboot fixes it but within 24 hrs it is back. MBP Mid 2010 10.8.2 Did not happen under Lion.

When this happens I just launch .zips with Stuffit Expander etc. unti I have to reboot eventually for other reasons.

No Default Folder installed.

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.

Try this,

Make sure that the Archive Utility is not running.

1. Go to the Apple Menu
2. Select "Force Quit...". The "Force Quit Applications" dialog box will open.
3. 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.
4. 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:

YourBootDiskName\

Users\

YourUserAccountName\

Library\

Preferences\

com.apple.archiveutility.plist

Restart immediately.

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

Likewise, on a MBP Mid 2009 running 10.8.2, i.e.:

deleting the com.apple.archiveutility.plist preferences file did not improve things. Repairing permissions and immediately rebooting didn't help either.

I have the same problem. MBA 2012. It seems to happen randomly (I'm sure not) and a reboot fixes it.

Greetings:

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.

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.

Good news. Ergonis replied quickly with a download link to a beta version that appears to fix this problem. At least it did for me. The link: http://www.ergonis.com/downloads/beta/

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.

Good luck.

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.

I understand that there are no inits in OS X (firm grasp of the obvious), which is why I said that "what used to be called." If the bug were in OS X, however, as you imply, it's a bit unclear how the problem could be resolved through updating a third-party app that's clearly conflicting. No desire to get into a debate here. Many forum users seem to come here to argue. It's a waste of time. The information I posted for you was in the spirit of being helpful. There is no question for those of us who were running Typinator prior to the new beta (full release to come out next week) that this was the source of the conflict rather than a Kernel Extension, Services daemon, API, etc.—but by all means, I respect your right to explore anything you may suspect is cause, ignoring the hard evidence I've presented here, confirmed above by psub, that a third-party app was indeed the source of the problem. Or you could just spend a bit more time checking out the third-party apps on your system before jumping to the conclusion that it's the OS. You did post a reply awfully quickly. Either way, good luck. And you're welcome.