*facepalm* Of course. Not the first time that has bitten me either.

lol - nor me. Aint appleScript fun? :rolleyes:

More fun than trying to duplicate this functionality on the windows machines at my shop.

Well it works, usually. I'm still trying to find what is breaking it. Sometimes (seemingly right after the shell scripts), I get an apple event error and it all stops. I believe its actually timing out after a large (>50GB) directory to tar, but I'm not sure since it doesn't say time out.

I'm about ready to re-write this in x-code so I can setup breakpoints, as it is I have put alerts at various points to check flow, but it isn't ideal.

Just try it with a with timeout block, see if that fixes it:

I remember that now. Though none of the old code I brought with me today has it. Some of these things could run for hours (multiples of >200GB folders).

I'll give it a shot for troubleshooting.

well, if they could really run for hours (yikes) you might want to rewrite this as a stay-open application: basically fire off the tar command as a subprocess then use the idle loop to periodically check to see if the subprocess is complete. that's a more convoluted script (you'll have to recover and store the process id of the tar process and check for it in the idle loop, and if it's more efficient you might launch multiple subprocess and wait for them all to be done), but at least you'll avoid having that frozen script thing you get when you run long tasks as simple scripts.

Yay rewrites! They literally can run for hours.

Just a high level overview, this project is for a tech shop I do work for that does quite a bit of data recovery. The goal is that once a recovery is done (typical is 80GB, but we're seeing more an more multiple hundred GB ones), to tar up the recovered data, put it on our server for safekeeping until pickup, and clear the space off the tech's workstation's drives so they can keep working.

This is something we'd run overnight, and I wouldn't be surprised to see it take hours.

Thanks for everyone's help and advice so far, by the way. I really appreciate it.

And, just for fun, I tried the timeout thing. Same error (and now I've also seen it happen within 5 minutes, so probably not a timing thing).

well, then what I'd do is throw in a bunch of log or display alert statements and see what the last command executed before the error is. that should point to the issue. which apple event error are you getting?

Yes, I know how to do that too.

The point I was trying to make was that, although you can keep switching back and forth between POSIX paths and HFS paths, the constant switching makes your code both harder to read and more error-prone. It's too easy to get the path separators mixed up and/or duplicated and/or omitted, too easy to forget which variables currently hold POSIX paths, which hold HFS paths, and which hold actual files/folders/aliases/URLs. The constant repetition of the "POSIX path of" mantra clutters up the code, making it less readable.

As foreign as HFS paths may seem to people more comfortable at the command line, your AppleScript code is cleaner if you use them.

When in Rome, speak Latin. When in AppleScript, speak AppleScriptese. Translate to POSIX when you need to go to POSIX-land, but translating prematurely just makes things more complicated.

And, how do you say Piña Colada in Spanish?

La bebida de Gringos.

By way of example, consider:

Create a test file with, for example:
date > ~/Desktop/Summary\ for\ 12:25:2010.txt
and then run:
Only path1 is correct. path2 gets the path separators mixed up. path3 has duplicate path separators.

And if you even dream of playing games with text item delimiters and manipulating path separators explicitly, you're missing the point.

I haven't been able to test again until this weekend. It is throwing "AppleEvent handler failed."

It appears to between the end of the file getting tarred, and the beginning of the finder copy. Usually the error comes up when the .tar.gz file is its final size, but the finder copy never starts.

well, best guess then is that it has something to do with the mounted share. Either the share is not mounting fast enough and the Finder is trying to write to a non-existant disk or there's something wrong with the open location command. try these diagnostics:

1. Make sure the disk is mounted, comment out the if not (exists disk "Archive")... block, and see if the script works if it doesn't have to deal with mounting the share.
2. Copy the if not (exists disk "Archive")... finder tell block to a different script and see it will by itself (a) mount the disk correctly, or (b) throw errors if the disk is already mounted
3. if (1) and (2) check out try moving the if not (exists disk "Archive")... tell block to the front of the script, right after the on open line. that will give the system more time to mount the disk while it's processing the tar files. or you could write in a delay-check loop, but likely mounting the disk earlier will be sufficient.

Logic eludes me when I'm banging my head on a brick wall sometimes...

Archive is a local volume on the machine I'm testing on, it should always be true.

I'll loop the volume check in another script and see what happens.

I'll also put it out there that the same error occurs on 3 machines. 1 running 10.6.8 and the rest running 10.6.7. Archive is a local disk on mine, the other two have to mount it over the network.

The "AppleEvent handler failed" thing is fairly specific - it points to a command in an application dictionary or osax that is not implemented (or not implemented correctly, anyway). literally what it's telling you is that the target app received an apple event from applescript but can't find an internal handler that's supposed to be there. In this particular case (starting from the do shell script and moving down):

• copy in line 20 is part of applescript core - no problems there.
• duplicate in line 28 is a known-functional command in the Finder, no problem there.
• that leaves something to do with the open location command

now it might be a problem with calling open location (part of the Standard Additions osax) from inside a Finder tell block. you could try this and see if it works:

That is something I never knew, and might help with troubleshooting.

Also, I just realized I never posted the current code.

That tell block is now:
Open location didn't work properly. Mount volume (and open location) are both part of the StandardAdditions, which I thought could be used anywhere?

Apple tightened things a bit in 10.6, so that osax couldn't be used quite as freely as they were before. the problem is name conflicts: for instance, if you have a command in an app called "cease fire" and a command in an osax called "cease" there is some ambiguity about which command was intended. So now what applescript sometimes does is seek out a command in the application dictionary but not propagate the search to osaxen (hence you get a 'handler not found' error rather than the script trying to run an incorrect command).

It's more complex than that, obviously - you often can use SA commands inside app tell blocks - but I don't know where or why it works when it does, so I take the conservative route and try not to use osax commands in tell blocks.