All, I apologize if this is something that I could have found in the documentation but I'm not seeing it. Additionally, I couldn't find a better place to pose this question than launchd-dev, and this is really more of an end-user question. For a launch agent with multiple watch paths, how does one pass the path that fired the event to the program arguments? Thank you kindly!
At 15:47 -0600 17/2/10, Errol Sayre wrote:
For a launch agent with multiple watch paths, how does one pass the path that fired the event to the program arguments?
Your agent should monitor all of the paths it's been configured for. Otherwise it would be subject to a race condition: 1. user touches path A 2. launchd launches the agent with path A, but it takes a while to start up 3. user touches path B 4. agent runs and processes path A 5. path B is never processed S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On the same subject, and apologies if this has been addressed elsewhere (I searched the archives to no avail), but does WatchPaths have the ability to pass the name (or path) of the item that triggered the job? In other words, using AppleScript folder actions, one can get the name of the item received in the folder. Is there a similar way to get this with WatchPaths? The receiving folder could have hundreds of files in it, so iterating through the folder, looking at mod dates, etc, wouldn't be stable enough. On Feb 18, 2010, at 6:11 AM, Quinn wrote:
At 15:47 -0600 17/2/10, Errol Sayre wrote:
For a launch agent with multiple watch paths, how does one pass the path that fired the event to the program arguments?
Your agent should monitor all of the paths it's been configured for. Otherwise it would be subject to a race condition:
1. user touches path A
2. launchd launches the agent with path A, but it takes a while to start up
3. user touches path B
4. agent runs and processes path A
5. path B is never processed
S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
At 10:43 -0500 18/2/10, Brian Hanson wrote:
The receiving folder could have hundreds of files in it, so iterating through the folder, looking at mod dates, etc, wouldn't be stable enough.
launchd watches directories via a kqueue, which doesn't tell launchd about the item that changed. Thus, the answer is no. You will have to look at the directory and work out what to do. But you have to do that anyway. Even if the launchd told you about the changes it saw, you'd still have to deal with race condition I described in my previous email. Ultimately you need to think of launchd's launch-on-demand mechanism as being 'level triggered'. The job doesn't hear about specific events, it hears about the existence of a certain state. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
A follow up question: Is it possible to specify that a WatchPath respond to events inside sub-directories?
At 12:57 -0600 18/2/10, Errol Sayre wrote:
Is it possible to specify that a WatchPath respond to events inside sub-directories?
No. Mac OS X has technology for doing this (the FSEvents framework), but it's hard to integrate into launchd because of layering issues (launchd is the first process on the system, so it can't depend on services which are themselves provided by higher-level processes). If you need to watch an entire directory hierarchy, you'll have to use FSEvents directly, and thus not launch on demand. One option is to write a small, low-impact daemon that does the FSEvents thing, and have it launch (probably via a launchd-arbitrated IPC) your full daemon when something interesting happens. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
Thanks. That's what I thought. The scope of my project is too small for me to write an app for, especially since one that does something very similar already exists: (http://incident57.com/less).
participants (3)
-
Brian Hanson
-
Errol Sayre
-
Quinn