Yes. One problem with ‘do shell script’ is that there is no intermediate feedback - the AppleScript containing the do shell script command continues immediately after the do shell script is passed to the shell unless an error comes right back. Also, have you checked with the contextual menu item (right click on the folder) ‘Configure Folder Actions’ that the folder action is active? I’ve been taking that for granted. If you comment out the shell script and drop a single file on the folder does it get duplicated and moved?
Just as well it does not trigger now. When you rename a file in an ‘activated’ folder, the folder action triggers again - it is a new file to the FA, and you end up in an infinite loop. The usual process is to move the file first to another folder and then continue from the script to process the file for a name change while the file is there. In your case, you might have jhead make that transfer as it processes each file. In the meantime, the Folder Action could ‘watch’ that folder’s size, and when it had been stable for longer than your process ever takes, begin duplicating and moving those files. Waiting goes like this:
set tFolder to choose folder -- as an example
set Size_1 to size of (info for tFolder) -- get initial size
delay 3 --wait 3 seconds, or whatever
set Size_2 to size of (info for tFolder) -- get a newer size, perhaps bigger
-- repeat until sizes match
repeat while Size_2 ≠Size_1 -- if they don't equal, loop until they do
set Size_1 to Size_2 -- new base size
delay 3 --wait three seconds, or whatever
set Size_2 to size of (info for myFolder) -- get a newer size
end repeat -- once the sizes match, the files are all in
-- continue with the duplicating and moving of files from tFolder
-- delete the originals in the active folder.
Another common problem, however, is that Folder Action scripts will begin processing scripts when triggered and miss the end of a large list that has been dropped. Delays help, but my usual practice is to promptly abandon the folder action approach and instead use a stay-open ‘on idle’ script to do the work.
If you have not used them before, they go like this:
on run
-- do setup - this runs when the application is started to set things up.
-- It is not necessary to have an 'on run' handler. The on idle
-- handler runs for the first time immediately after this anyway. If you want this to
-- run all the time after every login, list it your startup items.
-- Quit it from it's dock icon.
end run
-- 'on idle' runs immediately following the 'run' handler if there is one, and
-- thereafter on the interval specified.
-- (An 'on run' handler is not required, so omit if there is no setup)
-- In this section, you would see if there were any files in the target
-- folder, and if there are, process them.
on idle
-- In this section, you do your script operations every interval
return xx -- do this every xx *seconds*.
end idle
on quit
-- do stuff - assumes you want to clean things up or save
-- preferences or variables before the program quits. This section
-- runs only if the application is quit from the dock, or by any
-- other means.
-- if there is an on quit handler, then 'continue quit' must
-- be the last statement or the script will not stop!
-- The presence of an 'on quit' handler 'intercepts' the
-- system command to stop, so it will not complete the
-- quit process until notified to continue. 'continue quit'
-- does that.
continue quit
end quit