Folder Action Dispatcher

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.

Hi, I have try the go "Folder Actions Setup..." contextual menu, but rainbow ball and crash. I very helpless downgrade to Mavericks now.😕

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.

in reply to schwerd and Hen3ry:

Two files in your user Library to check. Note the differences in the two names:

1. ~/Library/LaunchAgents/com.apple.FolderActions.folders.plist
2. ~/Library/Preferences/com.apple.FolderActions.plist

The first one will have a list of file paths to where anything with a Folder Action may be. If there are any items between the "WatchPaths" and "" the System will still try to run Folder Action Dispatcher, and, most likely will crash or at least consume vast amounts of cpu cycles.

The second plist will indicate the true status of of Folder Actions being enabled or not. Just after the 'key' "folderActionsEnabled" will be a Boolean value. It could be either 'true' or 'false'. Unless it is 'false', Folder Actions are still enabled, regardless of what Folder Actions Setup says.

A re-install, may correct these files (and whatever caused the 'Dispatcher' problem) or it may not. That is probably the simplest step, though it will be quiet long, of course.

The second method is what I used. First, make a copy of these two files to your Desktop. Second, edit those files. You can edit them with TextEdit if you make sure that you save the changes as a plain text file (.txt). If it saves the file and leaves the ".plist" extension, you're set to go. If it doesn't, just change the 'txt' to 'plist' and click OK when the System asks if that's really what you want to do. Lastly, drag these two, edited, files back to the appropriate folder. You may want to log out and back in to be sure the OS 'sees' the changes you made. Hope that helps!

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!

GREAT! 😎 🙂

! did a similar 'inspection' routine on another Mac (a mini that I had used, sparingly, with the ßetas) and found the pristine files as a guide.

There are two profound lessons from these exercises:

1. Milages do, indeed, vary!
2. Always have a spare Mac running the same OS! $$$!

Just hope everyone can find a solution that works! Better yet, Apple figures out what the problem is and fixes it. There are several thread here and many posters are really upset.

Fortunately, the two plists I mentioned are the old, XML type. Several others I 'played' with required Xcode, since they are the newer compiled type. I didn't want to mention the need for editing those files as most people don't have/want/need Xcode.

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!!! 😁

DragonDave:

Thanks for your response.

Yeah, seems our experience was a bit different...

I think I observed that FAS did not refresh its preference file, which I had trashed. But I could be mistaken. At this point I'm content to say, "I may have seen an exception to the apparent rule that trashed pref files get refreshed when the associated app is launched" and leave it at that. Next time I'll be a bit more careful about watching.

At this point, in 10.10.2, on two Macs, FAS is fully stable for me, but I'm not doing anything with it. If I had a compelling reason to try to use it .... but I don't.

For the record, my one single experiment with FAS a year or two ago: would it trigger a system notification when a file was added to the local folder of a cloud service (Google Drive) by a remote person with whom the folder is shared? Seemingly: "no". I found an inexpensive add-on (Insync) that does this very well --and in nested folders-- so I dropped the idea of using FAS.

xairbusdriver:

Yeah, let's hope we can forgive and forget... because --as is the usual case-- this stuff "just works".

Just a brief word about aliases: I use them a lot to organize my Mac, usually Finder aliases, but sometimes the underlying (?) link mechanism. Finder aliases work so well it is easy to forget that they have limitations -- especially in a world complicated by such mechanism as Cloud sharing. My current puzzle, for example: I have a folder 'XYZZY' on my hard disk. I make an alias of it, and drop that alias in my local Google Drive folder. Something non-trivial gets shared through the Cloud, but it whatever it is, it isn't the content of folder 'XYZZY'. Back in the direction of our topic: I wonder what happens if you try to unleash Folder Actions on an alias, maybe once or twice removed... Makes my head spin!

Folder Actions seems to have a lot of potential. Anyone know of a collections of Cool Uses of this mechanism? If so... I might be tempted to test fate by trying my newly-fixed Folder Actions subsystem.

Hen3ry wrote:

Folder Actions seems to have a lot of potential. Anyone know of a collections of Cool Uses of this mechanism? If so... I might be tempted to test fate by trying my newly-fixed Folder Actions subsystem.

You be a braver should than I, my son! 😝 May the force be with you!

Hi Brendon,

I had a similar problem and I could not simply stop using Folder Action Scripts (FAS). From within a OS 9 emulator (SheepShaver), I used FAS to print files that were added to a specific folder on the OS X side. While this is not a solution for every case, it can give some clues to workarounds.

Since using FAS in my personnal user account ignited the Folder Action Dispatcher (FAD) like you all described, I tried it in another user. My tests proved that the problem was only in my personal user account. FAS worked perfectly in any brand new and fresh user. I was left to try to point out the conflicting process or processes.

At first, my search brought me near Dropbox and some other cloud backup service. It made sense since these services did, like my FAS, watch folders to see if any items were added or modified. I installed Dropbox in an existing user where FAS was not a problem .... and the FAD problem began. Good ! I uninstalled Dropbox in that same account and the FAD problem was gone. Very good ! I really thought that I had found the culprit. I then uninstalled Dropbox in my personal user account ... and it did not fix the FAD problem. I then created a brand new and empty user. I installed Dropbox .... and the FAS was working without a glitch. I tried that in a few new users, and I can conclude the same thing: on my computer, FAS works perfectly in any new and fresh user account. So Dropbox is not the problem but could be involved. Gosh ... my problem was not solved.

Time was missing. My work was halted for 3 days. I had to find a way. Since my case involved a process (print) that could be executed from another user in the background, I thought about creating a FAS from a user account that did not have the FAD problem and to use the Shared folder that is accessible from any user to print. I have a Guest user account, that t is always logged in ... and it doesn't have the FAD problem. From that account, I created a FAS folder in the Shared folder.

So, from my personal user account, I am able to add a file to a folder in the Shared folder ... and then, the FAS executes from the Guest user account were there is no FAD problem. And it works ... and it has been working for a while now. It should probably be working until a conflicting process is installed in the Guest user account. I will not try to reinstall Dropbox in that account to see what will appen. It works and I will keep it this way ... until a permanent fix comes from Apple.

Hope this can help somebody else.

Robert Lespérance