Yep. FA can detect a batch transfer performed by the Finder, for example, when the user selects a group of files in the Finder and drag-n-drops them into the FA-enabled folder as a single operation. In your case though it's just seeing a sequence of separate file copy operations, so it sends a separate 'adding folder items' event for each. It has no way of knowing otherwise; it just does what it's told.

"""So, my configured Folder Action can fire up seemingly at random for as long as I am logged in, even though the files have already been imported and moved. If anyone has any idea what is going on here, please let me know."""

It's not random. Put simply, your problem is that batch-processing and event-driven programming tend to mix like oil and water. :p

FA is simply working its way through each of the 'adding folder items' events that have been added to the event queue while your script was still working on the first one. If your script was more polite, it would operate only on the file(s) specified in the event's 'after receiving' parameter. Instead, you're using FAs merely to trigger a batch processing script the first time an 'adding folder items' event is received, telling it to wait an arbitrary length of time before going off to process an entire folderful of files that have [hopefully] appeared during that wait. By the time FA finishes processing the first event and starts on the second one, you've already finished the entire job. How rude!

A couple options:

1. What you really want is to trigger the batch processing script just once, immediately after BFE has finished doing its job. That's usually easy enough to do when you're controlling an application yourself via Apple events, since well-mannered apps don't return until they've finished the operation that the event triggered. In situations where your script isn't in charge of an application, you're in a bit of a pickle though. It's extremely rare for an application to offer some kind of notification service [1] that would allow you to register your script to be triggered by, say, a 'did finish synchronisation' event. I don't imagine for a moment that BFE falls into that category.

2. Next nearest thing, as you've already found, is to attach FAs to BFE's download folder. The clean solution would be to rewrite your script so it only operates upon the file(s) passed to it via the 'after receiving' parameter. The hacky solution would be to check the download folder actually contains some files before going any further (I think this is what you meant to do, but you had it wrong):

on adding folder items to source_folder_alias after receiving these_items

 	tell application "Finder" to set file_count to count files of source_folder_alias

	if file_count > 0 then

 		delay 30 -- wait for everything to transfer from the phone

	 	select_iphoto_library(myLibrary) -- ensure we have the right library

		[...]

	end if

 end adding folder items to

This will ensure that the second and subsquent events are quickly skipped over if there's nothing left to do. Just say a little prayer and hope that your delays are set long enough not to screw things up.

3. Write yourself a daemon that regularly polls the download folder. If it notices new files appearing in the folder, have it keep polling until it's confident they've stopped appearing, then trigger your batch-processing script. If you don't want the daemon running permanently, use a folder action to launch it and have it shut itself down when done. You could use a stay-open AppleScript applet for this if you want; just put your polling code in its idle handler and set the delay between idle events to a reasonable amount.

"""I stumbled upon a curious fix. I wanted to look at the arguments that the Finder gave to each invocation of the script, which turns out to be a lot of work in AppleScript. I settled on a Perl script that I called with do shell script. The script reports the complete list of files I transferred, which is what I wanted to inspect. I wanted to see what Folder Actions thought I was adding to the folder during these random invocations.

As long as that little debugging code was in there, the random invocation problem disappears."""

Sounds like a Heisenbug. It suggests there's a bug in your debug code that causes it to error under certain conditions, those conditions occurring when your files have already been processed and moved by the time your script is notified of their arrival. Because your logging code appears before your importing code, if an error occurs in the former the latter never gets a chance to execute. System Events has no way of knowing how to deal with any errors that occur in your attached script so just silently squelches them, leaving you none the wiser as to why your import code didn't run. This is why during development and testing it's always wise to wrap a 'try | on error e | display error e | end try' block around the code in each event handler so you'll immediately know if something goes wrong.

HTH

has [http://freespace.virgin.net/hamish.sanderson/appscript.html]

[1] System Events and Mail are a couple of examples with their Folder Actions and mail filter rules respectively, and even they are incredibly limited in what's on offer. Certainly nothing to write home about. It's such a sorry situation that there's now a third-party application available that enables you to attach scripts to applications' GUI objects to intercept events sent to them; an incredible kludge, but that's how desperate folk are. [/rant]