Folder Action Dispatcher

Why isn't Apple fixing this!? It doesn't seem to be a a problem on my 27" iMac, but a troubling issue on my 17" MacBook Pro. Big enough issue to to stop using the product. I've already recommended to a few people to NOT buy a Mac because of it.

I, also, saw the process grow to 20 GB on my 16 GB iMac running Yosemite. Now, I admit that I had not noticed any particular sluggishness with my computer, but I WAS aware of a lot of disk thrashing. I assumed that was Time Machine doing it's thing, but since disabling Folder Actions, I've come to believe that it was a ridiculous amount of swapping into and out of virtual memory.

In my case it was a RoboForm script that had resulted in the enabling of Folder Actions. The name of that script was removeRoboFormHandler.

Does anyone know if this is likely to adversely affect the function of RoboForm? I ask because I cannot discern any difference in RoboForm's performance, but I'd deduce that the script had to be there for some reason.

I also noticed that the script, remove RoboFormHandler was listed in Folder Actions Dispatcher, but there are 2 listings for this script. I'm also curious about what purpose the script serves and why there are 2 listings. I unchecked both, and my system CPU usage went way down.

I had three scripts that were red and said something about "quarantine". I deleted them. I hope that solves my problem. I appreciate the thread, but I don't feel like I knew what I was doing exactly. Hopefully nothing to dangerous.

Every day I try to use my machine and it is frozen because all the memory is being used by that stupid process.

just updated to Yosemite.... have done on other machines without this problem... but now this is killing me..... Folder Actions Dispatcher is hammering machine at 90+% CPU usage no matter what I do...

the odd thing, after reading this thread.... I have NO folder actions set... it's not even turned on... and yet... it's completely taking over my machine... Activity Monitor shows it running 91 - 94 % of CPU... but it's turned OFF everywhere I've looked for it.

HELP!!!!!!! how do I kill this menace????????

hasn't happened on either of my other two machines... both running Yosemite just fine.... have never ever seen this

1) What version of Yosemite are you running?

2) Can you verify how you're checking to see if any folder actions are set? (as far as I know, no one's seen this if they haven't had folder actions turned on, and referencing a specific folder(s)). Also, do you have other accounts on that machine that might have them turned on?

3) As far I can tell, this problem has been fixed with Yosemite 10.10.2. I'll know more on Monday (after I let it run all weekend), but after letting it run a couple of hours I'm not seeing either the CPU or the RAM problem. When I was seeing the problem, it was quite apparent after watching things in the Activity Monitor over the course of a half-hour. I'm not seeing anything like that now.

Thanks...

First, here's a ink to a post on ways to handle this problem: ttp://www.macissues.com/2015/01/30/fix-folder-actions-dispatcher-using-high-cpu- in-yosemite/l

My problem was that I had NO Folder Action Setup... in any contextual menu! That made it extremely hard to follow any of the threads about this problem, since the first step in most of them was "use the Folder Action Setup app to...". 😮 I had looked at the Keyboard Pref Pane->Shortcuts list of possible items yesterday, unfortunately, my frustrations got the better of me. I finally found the item in the 'Files and Folders' group of the above Pref Panel. For reason I can't fathom, it was not checked. I have no idea if that's the default, but it seems unlikely. 😕

Of course, by the time I found the setting, I had already eliminated the 'Dispatch' crashing (at least for the last 5+ hours) by editing the ~/Library/LaunchAgents/com.apple.FolderActions.folders.plist There is a 'key' value there named "WatchPaths" with an array (list) of paths to watch. WOW! 😝 All I did was to comment out the last four (of the 14) items and re-save the file. There is one that looks at "Internet Plug-Ins" in my user Library, the other three look at the entire three "Library" directories (user, /System/Library, and /Library). I will slowly UN-comment those, one at a time, when I have the time.

In addition, I completely removed all the Services items in ~/Library/Services/ since none of them were particularly useful or used by apps I use often.

Of course, since I made two completely different changes, I'll not know which (or IF) made things improve.

Do you have "Folder Actions Setup..." in a contextual menu (right-click or control-click) on a folder in Finder?

1. If you do, try to use the window that comes up and UN-check the "Enable Folder Actions" item at the top of that window. Are there any listed items in the left-hand box?

2 If you do NOT have that item in a contextual menu, please let us know.

running 10.10.2

verified that NO actions turned on anywhere

continuing to run at 90+%

killing machine

with folder actions already OFF everywhere, none of the proposed solutions applies...since they all advise "turn off actions"

likely going to erase drive and go with a virgin install to see what happens.... but I am seriously not happy

I think my experience is similar.

I installed 10.10.2 a few days ago. I began noticing CPU usage (Activity Monitor, CPU Usage Window) meter were unusually-unreasonably high for all 4 processors. I investigated by looking at Activity Monitor, All Processes, and saw Folder Actions Dispatcher consuming 90%+ of a CPU.

I picked a random folder, and looked at Services-->Folder Action Setup... Enabled, and no actions were listed. I disabled Folder Actions, and CPU usage returned to reasonable levels.

What happens if I re-enable Folder Actions? I opened Services-->Folder Action Setup... for a random folder. When I enabled Folder Actions, the app hung (spinning pinwheel cursor) and I again observed unreasonably high CPU load. Fixed with Force-Quit of the app.

Fortunately, I can do without Folder Actions, and I'll leave them disabled, but it would be nice for this issue to be fixed, in case I do need them.

xairbusdriver:

Thanks for your suggestion. Unfortunately, it did not work for me ... but it led me in the right direction.

First, as you suggested I tried editing the files with TextEdit and then using the xCode editor, which supports structured viewing+editing. Did the logout-login dance. No help. Tried several variations.

The failure of your method suggested to me that one or more of the files was corrupted. Easiest way to get fresh copies? I have access to a virtually identical Mac, and I performed a direct file transfusion of all the visible, presumably relevant ~/Library files from it to my afflicted Mac. These files:

~/Library/LaunchAgents/com.apple.FolderActions.folders.plist

~/Library/LaunchAgents/com.apple.FolderActions.enabled.plist

~/Library/Preferences/com.apple.FolderActions.plist

I assured myself that Folder Actions was functioning normally on the donor Mac by doing a simple test first. Then I removed the test action and disabled Folder Actions on that machine. Of course, yes, I saved the files on the recipient machine before replacing them.

Problem solved.

Disclaimer: YMMV. Don't try this if you are not fully confident...

Thanks!

The plist file in ~/Library/Preferences is a binary plist file. The other two are not (at least on my machine). If you want to edit a binary plist file, you can use TextWrangler (free). It handles it just fine. XMLSpear also handles them.

However, note that those plist files get cached by the system. In fact, in my tests, I saw my changes revert if I started the Folder Actions Setup task. The only way I got my changes to "stick" was to reboot right after editing the plist file.

xairbusdriver:

DragonDave:

Thanks for your comments.

Editing plist files seem iffy, generally. (I wonder what proportion of the time this procedure is actually successful?) If I've got a reason to try, I prefer using the Xcode editor, as it parses whatever the internal format is, so it seems, interprets the internal format, presents consistent choices, and may clear up corruption by writing back a consistently formatted file. Do TextWrangler and XMLSpear have this characteristic? I'm guessing those are hugely smaller than Xcode, so a lot more convenient for people who don't need to deal with Xcode. (Note: I've actually used Xcode for exactly one trivial programming project in all the time it has existed.)

Yeah, the plist files are likely cached. I did logout-login after editing them, but it could be a bit iffy to control this mechanism exactly. I think I verified that my changes were in the files after re-login, but I'm not certain.

I'm puzzled by the apparent failure of the app to rewrite its preference file. As long as I remember deleting a preference file has triggered a rewrite, which makes doing this a valuable glitch-fixing tool. No longer? That would be a shame.

Let's get back to basics, try to record information that might be useful in fixing this problem. Maybe someone is watching…

I did not read the current thread carefully, or look for other similar threads —hey, I've got a lot of work to do, too— but it is my general impression that some people saw this problem only after installing 10.10.x, yes?

My experience, n=2, is that a system that had no Folder Actions, ever, had no problems after the install. My other system had a single Folder Action defined, but Folder Actions were disabled. I think the problem manifested itself immediately when I selected Services—> Folder Actions Setup… That is just a way of way of launching

…/System/Library/CoreServices/Folder Actions Setup.app

which, for me, immediately soaked up way excessive CPU cycles and hung. I _think_ Folder Actions were still disabled at this point… Two possibilities come to mind:

• The app looked at the PLIST files, encountered corruption, and got very confused

• The app wrongly determined Actions were enabled, tried to do some Action processing, and got confused.

Either could be explained by PLIST file corruption or by a subtle incompatibility between the pre-10.10.x format and the current one.

Obviously these are WGs (wild guesses)…

Well, TextWrangler reads and writes the binary plist files just fine. It presents the data as XML, so as long as you don't mess the XML up, it should be fine. Though you're right, Xcode wouldn't allow you to screw things up as much as TextWrangler would.

Getting past the caching is a little trickier in my experience, though rebooting always seems to work (just logging out typically doesn't do it for me). Results also vary depending on the app that controls that particular plist file. I've seen cases where the changes got picked up after several minutes.

I'm not quite following the comment about the "apparent failure of the app to rewrite its preference file". At least with the the Folder Actions Setup, that worked fine for me. Not for you?

And yeah, this issue seems to have occurred with Yosemite. In my particular case, there was one particular folder (~/Library/LaunchAgents) that if you had that in your list, the Folder Actions Setup app would start chewing up both CPU and RAM, sometimes enough to render the system unusable. This seems to be fixed with 10.10.2. With another system that just recently got upgraded to Yosemite, the Folder Actions Setup app seemed a bit flakey until the plist files were deleted, and I let the system recreate them. It's working fine now. You'd have to look at the previous posts for more details.

Marginally related info:

I found an entry from an app (Default Folder X) in the com.apple.FolderActionsSetup.plist, actually, it's still there. I contacted the developers asking if they used Folder Actions when writing to that plist. They didn't actually answer either of those questions, but they did comment about the 15 'alias' "folders" in the com.apple.FolderActions.plist (which I simply deleted, thereafter finding that I could uses Folder Action Setup app... finally). I'll simply quote the responce about alias' in plists:

"Alias entries are particularly problematic in preferences because they're just a blob of binary data (rather than settings that are text strings). If anything gets scrambled, the application tries to use the data anyway, sometimes with disastrous consequences like crashes."

Each of the 15 entries had several hundred bytes of 'data' that I assumed was simply an image. Even if that's all it was, it may be exactly what was causing problems when 'Dispatcher' tried to use it. At least it re-inforces what the developer claims can happen. Who knows how the 15 entries were created or why. Apparently it was a one-off, it's not returned on my system, but you can guarantee I'll be watching for it with the next update! 😮 😉

Here's hoping we won't see this ever return or that Apple considers it important enough to solve. Frankly, I don't even want to read "FolderActions" anything any more!!! 😁