this is an odd one,
using the adding items to folder script, I’m trying to distribute files to various folders. When files are small in size, it works great but when files with larger, the whole things bombs…
is there a way to make the script wait till all files copy first or something? …anything to make it hold its horses?
Browser: Firefox 1.0.1
Operating System: Mac OS X (10.3.9)
Maybe verify file size to be sure copy is complete? I’m sure there must be a better way, but I don’t know what it is.
You can use
with timeout of 600 seconds
--put processes here that take the time. The amount of the time can be varied quite a bit. This allows for 10 minutes for the process to finish. If it finishes sooner that is alright. If it takes longer then it will need to be adjusted.
end timeout
This seems to work for me when using Stuffit to compress large files.
PreTech
‘with timeout’ adjusts the length of time that the script will wait for an acknowledgement of the completion of a command before deciding that something’s gone wrong. If the command fails to signal its completion within this time, the script throws a timeout error. I forget what the default time is (a minute or two), but it can be changed by putting commands that are likely to take longer than this (such as stuffing large files) inside a ‘with timeout’ block which specifies an adequately large number of seconds. This doesn’t hold up the script if the command signals “done” before it’s actually finished. It controls the length of time that the script is prepared to hang around for the “done” signal.
My own experience with ‘adding items to’ folder actions is that they work perfectly well, no matter what the file size or number, if all the files of a batch are moved to the watched folder in one go. If they’re moved in short, overlapping bursts, or if they’re saved directly to the folder from an application, then confusion might arise. Even overlapping bursts should be OK (in moderation) provided that the script acts on the ‘after receiving’ alias list and doesn’t bother itself with whatever else may be in the folder at the time.
That said, I don’t use folder actions in earnest myself. I just find it difficult to reproduce in tests the problems that people often complain about. Apologies if the above paragraph isn’t helpful. :rolleyes:
thank you, this works
Actually, Nigel, I believe you’re correct on both counts. 
The default timeout was originally 1 minute - but it’s evidently now 2 minutes. (I’m not certain exactly when this changed.)
As an adjunct to Nigel’s typically excellent and illuminating explanation, it may be worth noting that the ‘with timeout’ command applies only to applications that are targeted by a script. It doesn’t normally affect the application running the script (such as a script editor) - or the AppleScript environment itself.
Rather than try and guess when an operation is likely to time out, and then specify a timeout slightly longer than that, it may be a good idea to introduce as generous a timeout as possible. In other words, tell the target application to take as long as you are really prepared to wait. (The user always has the option to cancel if necessary). I often use something like:
You could also specify a timeout of less than the default period - if, for example, you wanted to make sure that a usually brief operation had completed successfully.
Trivia Corner:
Coming back to the original question, I’ve recently done a fair bit of testing on this type of thing - mainly because of the number of queries that seem to have cropped up just lately (in various places). Timeouts apart, I have to say that my experience concurs with Nigel’s - and that Finder normally waits for a move or duplicate operation to finish before handing back to the script.
I understand that Apple is currently aware of only a couple of Finder operations that allow a script to continue before an operation is complete. These are emptying the trash, and getting the size/physical size of a folder - the latter of which may return a ‘missing value’ on an initial attempt. (Both cases are considered to be bugs.)