There are actually three levels where Folder Actions can be enabled or disabled. The Enable Folder Actions menu item in Finder’s contextual menu corresponds to the least specific level of control. Your original script is setting the middle level. Try this:
tell application "System Events"
--.
set folder actions enabled to true
--.
end tell
If you use the Folder Actions Setup application, you may notice that each level corresponds to a checkbox in a different area of the application’s window. You can find the application in /Application/AppleScript, or you can launch it directly from the Configure Folder Actions. menu item in Finder’s contextual menu.
My names for the three levels of Folder Action control are user, user+folder, and user+folder+script (there may also be better or more official names). The user level is the master level. If it is turned off, no Folder Actions will ever be triggered for things done while the user is logged in (even if the user+folder or user+folder+script levels are enabled). The user+folder level controls all the scripts that are attached to the folder in question. If the user+folder level is disabled, no actions will trigger any of the attached scripts even if they are enabled at the user+folder+script level. Finally there is the user+folder+script level where you can control whether individual attached scripts are enabled or disabled.
So, for a script to be enabled, all three levels must be enabled (the user level, the user+folder level for the folder in question, and the user+folder+script level). If any one of them is disabled, the Folder Action script will not be triggered.
I reworked your script to make it easier for me to run (use path to instead of hard-coded volume and folder names), made it enable all three levels and also fixed a couple of potential bugs:
set myName to "from ftp server"
set myLocation to path to desktop folder as Unicode text
set myFolderName to myLocation & myName & ":"
set myScript to (path to Folder Action scripts folder from local domain as Unicode text) & "add - new item alert.scpt"
tell application "Finder"
if not (exists folder myFolderName) then
make new folder of folder myLocation with properties {name:myName}
set myItem to result as Unicode text
else
set myItem to myFolderName
end if
end tell
tell application "System Events"
if exists (first folder action whose name is myName) then
set myAction to (first folder action whose name is myName)
if not (exists (first script of myAction whose path is myScript)) then
-- folder is registered with Folder Actions, but does not have the specified script attached
attach action to alias myItem using myScript
end if
else -- folder not registered with Folder Actions
set myAction to (attach action to alias myItem using myScript)
end if
set myAttachedScript to (first script of myAction whose path is myScript)
set folder actions enabled to true
set enabled of myAction to true
set enabled of myAttachedScript to true
return {folder actions enabled, enabled of myAction, enabled of myAttachedScript}
end tell
Bugs from the original version fixed here:
¢ If the target folder (myFolderName) did not exist, myItem would be be the Finder folder object for the newly created folder, not the path string. This would cause an error when making it into an alias for attaching the script. So always, make sure myItem is the path string, not the folder object.
¢ I am not sure that test in the System Events tell block would ever return false (it would always try to attach, and end up getting a duplicate error if it was already attached), so I rewrote the logic there and covered a previously uncovered situation.
¢ This script enables all three levels in all cases: whether the script is already attached, needs to be attached, or if the folder was never even in the Folder Action registry.
Remaining Bugs:
¢ Using a filter reference based on the name of a folder action object is prone to problems. There can be multiple folder action objects with the same name (one could have multiple folders called “from ftp server” in different parent folders, all with attached Folder Actions). Also, the name of a folder action object does not necessarily have to correspond to the name of the folder that it controls (rename a folder after a Folder Action has been attached, or programatically change the name of the folder action object). A better way would be to filter based on the path of the folder action object, but that never seems to work in my testing.
¢ Automatically enabling the user or user+folder level that was previously disabled might have a side effect of reviving scripts that the user had intentionally disabled by turning off a higher level control. This might surprise the user when previously disabled scripts start being triggered. In a previous program I wrote, I took pains to disable any previously enabled lower-level items before enabling a higher level item. It was ugly because I could not get the appropriate System Events filter references to work, but I felt it was the right approach for my purposes.