:?:
We have created what i understand to be a very simple script. It is a folder action that simply duplicates the file to another folder then moves the original file to yet another folder. (these folders are watched folders for other purposes) .
All the folders concerned are located on an OSX server running 10.2.8. Workstations which will be creating the files are running OS 9 and OSX 10.3
Here is the problem. When the folder action is attached using one of the 10.3 workstations all is well provided that workstation is running.
When the folder action is attached using the “attach folder actions” script on the 10.2.8 server, the script will run only once. If ten files are placed in the folder at one time all ten will be processed. If one file is placed it will also be processed. But, if the one is placed after the 10 have run through or vice versa the script will fail when new files are placed in the folder.
A possible clue to the solution: If the script is changed to “duplicate” the files to both the other 2 folders it will continue to work whenever new files are placed in the folder. Problem with that is we would end up with GB’s of unnecessary files very quickly. If these files are manually deleted or moved, the script fails again when new files are placed into the folder unless the Folder Action is attached again.
The same script will work on an imac running 10.2.8 (non server)
The goal is to have the Folder action attached and operating without interuption, but not through the use of an individuals workstation. We would like the server to take care of it and cannot understand why it can’t
You could skip the folder actions altogether and create a stay open script application that checks the infolder at certain intervals. Folder actions require that files are dropped into a folders open window to work, whereas a script app like this doesn’t. It would look something like this (haven’t actually tested this particular one…):
on idle
tell application “Finder”
set fList to every file of folder folderToCheck
if (count items of fList) is not equal to 0 then
repeat with aFile in fList
duplicate aFile to folder folderToDupTo
move aFile to folder folderToMoveTo
end repeat
end if
end tell
return 60 – run at 1 minute intervals
end idle
Limbo: FYI, OS X’s folder actions don’t require open windows.
RipIt: It seems that folder actions still have some bugs in cases such as yours. Several users have reported problems when files are added while a previous batch of files are still being processed. Limbo’s suggestion might be the best way to overcome the problem.
Thanks Limbo for the script and Rob for assuring me there are others experiencing bugs. I trust someone more qualified than myself will be fixing them.
Anyway Limbo, the script worked once I had modified the Properties of course, BUT, there is now another issue and Im not sure how it could be related to the script but will explain anyway.
One of the watched folders is an “in” folder for Acrobat Distiller. However , Distiller will not distill the files that are moved into it via the script. They are indeed postscript files yet an error file is produced stating that the file is of type DATA. If the same file were dropped into the “In” folder directly without being processed by the script, Distiller will distill the file and produce a perfectly normal PDF.
The same script run in the same manner on a non server OSX 10.2.8 machine does not experience the same problem.
Usually when these things happen to me, it’s because the script has been moving files that are not yet fully copied to the watched folder (watched by the script). If a file is large the script could try to move it before it has completely arrived, and so leave it in a state not usable by distiller. This would be simple to test of course, by taking the actual ps file and manually run it with the distiller. The other possibilitiy is that Distiller tries to do something to soon, before the file is completely copied to the hotfolder, and so only sees part of the file.
None of the above explains why it should work on a non-server system, and not work on a server, so I have to admit I’m at loss here.
If it has to do with files being moved before they are ready, I use to test if they are open before doing anything with them. This can sometimes be done with at subroutine like this one:
on isOpenFiles(theFiles)
(* Takes a list of files and tries to open them with write permission. If a file is already open, an error is generated. The handler returns true in that case, otherwise false *)
try
repeat with theFile in theFiles
open for access file theFile with write permission -- test if the file is open
close access file theFile
end repeat
on error errormsg
return true --we got an error, file is open (could be a range of other errors too, of course)
end try
return false --if it works, return false
end isOpenFiles
Limbo,
I have eliminated the possibility of the file being too large as the problem.
The original ps file will distill through the distiller hot folder if moved there by hand (mouse)
When the file has been processed via tha script app (either the Dup line or the Move line) it will not be distilled.
Yet, if distiller is asked to open the file that has been processed by the app, it will distill it despite the fact that the type is “DATA”. But that defeats the object of watched folders.
So, we can determine that the script is somehow changing the file type to “DATA” from " " and the creator to “MPS” from"vgrd" . How , when and WHY is giving me a headache.
This is really very strange. I do this all the time in several scripts and have never had that kind of problem. All the script does (supposedly) is to use Finders move and copy methods, so the type of the file should not be altered by that.
"MPS " is the creator code of MPW Shell, the editor in Apples old programming environment, and when I do a search on my HD to see what files I find with that creator, it turns out to be a lot of Adobe-files. None of them are of type “DATA” however.
Can you confirm that the type and creator are correct before you drop the files into the folder the script watches, and that type and creator are changed after the script has moved them? Do the files have a file suffix (.ps)?
Unfortunately (cos it leaves us nowhere closer) I can confirm that the files type and creator are correct prior to using the script.
They are only changed after running through the script.
The files do have a .ps extension.
I should point out that one of the files (the duplicated one) is being picked up by a print Rip and it prints fine. The problem now is strictly that Distiller will not distill either of the files that are created after being processed by the script.
To add to the confusion of the matter Distiller WILL distill the file if it is opened directly with distiller rather than from its watched folder.
The file type/creator is bonus information which does not seem to be helping us. I have checked all I can with distiller and its watched folders and found nothing to suggest why it can distill a file if asked directly but cannot distill the same file from its hot folder.
Here’s a modified script that you could use to check what’s happening. It displays the type and creator of the file before it touches it, and after it is i moved or duped. Also there is code to change the type and creator code to something that works with Distiller.
property folderToCheck : "HD:watchfolder:"
property folderToDupTo : "HD:otherfolder:"
property folderToMoveTo : "HD:thirdfolder:"
on idle
tell application "Finder"
set fList to every file of folder folderToCheck
if (count items of fList) is not equal to 0 then
repeat with aFile in fList
set fType to file type of aFile -- get type and creator before any action
set fCreator to creator type of aFile
display dialog (("Creator: " & fCreator as string) & ". Type: " & fType as string)
set fDup to duplicate aFile to folder folderToDupTo
set fMove to move aFile to folder folderToMoveTo
set fType to file type of fDup -- get type and creator after duplicate
set fCreator to creator type of fDup
display dialog (("Dupfile - Creator: " & fCreator as string) & ". Type: " & fType as string)
set fType to file type of fMove -- get type and creator after move
set fCreator to creator type of fMove
display dialog (("Movefile - Creator: " & fCreator as string) & ". Type: " & fType as string)
-- and finally you can explicitly change the type and creator to whatever you wish
set creator type of fDup to "vgrd"
set file type of fDup to "" -- normally should be 4 characters, but you'll have to fill in whatever is needed (even if it's just spaces)
end repeat
end if
end tell
return 60 -- run at 1 minute intervals
end idle