Rjkjr

Q: Folder Action Dispatcher

Folder Actions Dispatcher sits in memory, and grows and grows until it consumes over 2 GB.  It will typically ask for as much as 50% of the CPU as well.  Then it usually crashes, but not before consuming the RAM that should be available for other applications.

 

I did some sleuthing, and found a com.apple.FolderActions.folders.plist file in the ~Library/Launch Agents folder.  Something is changing it very frequently.

Inside, the file contains the following script: 

 

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

  <key>Label</key>

  <string>com.apple.FolderActions.folders</string>

  <key>Program</key>

  <string>/usr/bin/osascript</string>

  <key>ProgramArguments</key>

  <array>

  <string>osascript</string>

  <string>-e</string>

  <string>tell application "Folder Actions Dispatcher" to tick</string>

  </array>

  <key>WatchPaths</key>

  <array>

  <string>/Applications</string>

  </array>

</dict>

</plist>

 

I conclude that some application somewhere is causing AppleScript to watch /Applications for changes, for some reason.  I don't know why this would cause Folder Actions Dispatcher to grow and grow as it does.

 

Questions:

  • is there a way to find the "author" or "owner" (a program) of the script and stop it?
  • I cannot delete the file -- are there innocuous changes to it that might cause it to stop behaving this way?


thank you

Mac Pro

Posted on Jul 26, 2014 9:01 AM

Close

Q: Folder Action Dispatcher

  • All replies
  • Helpful answers

first Previous Page 3 of 4 last Next
  • by MacMini_HK,

    MacMini_HK MacMini_HK Feb 6, 2015 5:01 AM in response to xairbusdriver
    Level 1 (0 points)
    Feb 6, 2015 5:01 AM in response to xairbusdriver

    I have "Folder Action Dispatcher" CPU full load problems, try to another guide, but no luck can't fix.

     

    Screen Shot 2015-02-06 at 8.56.32 pm.png

  • by xairbusdriver,

    xairbusdriver xairbusdriver Feb 6, 2015 7:10 AM in response to MacMini_HK
    Level 2 (160 points)
    Feb 6, 2015 7:10 AM in response to MacMini_HK

    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.

  • by MacMini_HK,

    MacMini_HK MacMini_HK Feb 6, 2015 7:01 PM in response to xairbusdriver
    Level 1 (0 points)
    Feb 6, 2015 7:01 PM in response to xairbusdriver

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

  • by schwerd,

    schwerd schwerd Feb 8, 2015 11:59 AM in response to DragonDave
    Level 1 (60 points)
    Feb 8, 2015 11:59 AM in response to DragonDave

    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

  • by Hen3ry,

    Hen3ry Hen3ry Feb 8, 2015 12:03 PM in response to MacMini_HK
    Level 2 (499 points)
    Feb 8, 2015 12:03 PM in response to MacMini_HK

    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.

  • by xairbusdriver,

    xairbusdriver xairbusdriver Feb 8, 2015 2:45 PM in response to Hen3ry
    Level 2 (160 points)
    Feb 8, 2015 2:45 PM in response to Hen3ry

    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!

  • by Hen3ry,

    Hen3ry Hen3ry Feb 9, 2015 11:50 AM in response to xairbusdriver
    Level 2 (499 points)
    Feb 9, 2015 11:50 AM in response to xairbusdriver

    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!

  • by xairbusdriver,

    xairbusdriver xairbusdriver Feb 9, 2015 3:20 PM in response to Hen3ry
    Level 2 (160 points)
    Feb 9, 2015 3:20 PM in response to Hen3ry

    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.

  • by DragonDave,

    DragonDave DragonDave Feb 10, 2015 5:28 AM in response to xairbusdriver
    Level 1 (15 points)
    Feb 10, 2015 5:28 AM in response to xairbusdriver

    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.

  • by Hen3ry,

    Hen3ry Hen3ry Feb 10, 2015 10:52 AM in response to DragonDave
    Level 2 (499 points)
    Feb 10, 2015 10:52 AM in response to DragonDave

    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)…

  • by DragonDave,

    DragonDave DragonDave Feb 10, 2015 12:04 PM in response to Hen3ry
    Level 1 (15 points)
    Feb 10, 2015 12:04 PM in response to Hen3ry

    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.

  • by xairbusdriver,

    xairbusdriver xairbusdriver Feb 10, 2015 12:34 PM in response to DragonDave
    Level 2 (160 points)
    Feb 10, 2015 12:34 PM in response to DragonDave

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

  • by Hen3ry,

    Hen3ry Hen3ry Feb 10, 2015 12:44 PM in response to DragonDave
    Level 2 (499 points)
    Feb 10, 2015 12:44 PM in response to DragonDave

    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.

  • by Hen3ry,

    Hen3ry Hen3ry Feb 10, 2015 1:11 PM in response to xairbusdriver
    Level 2 (499 points)
    Feb 10, 2015 1:11 PM in response to xairbusdriver

    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.

  • by xairbusdriver,

    xairbusdriver xairbusdriver Feb 10, 2015 1:16 PM in response to Hen3ry
    Level 2 (160 points)
    Feb 10, 2015 1:16 PM in response to Hen3ry

    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!

first Previous Page 3 of 4 last Next