Update: Jan tells us that in Leopard this issue is fixed. I have not tested it myself, but I certainly trust her.
Truth be told, I’m an AppleScript junkie. I love how easily I can write a simple program to give me a better or more natural interaction than it was designed for. As a result, I’m also a huge fan of Automator, which builds on AppleScript and makes development even easier (It reminds me of programming SCEA’s Carnage Heart).
Anyway, trying it out I discovered that Apple ran into an AppleScript bug that’s been around since Panther, and I can’t believe hasn’t been fixed.
The bug manifests itself as an “Applescript Error” such as :
– “Can’t get properties of alias”
– “Can’t get file type of alias”
and is followed by (-1728).
What’s going on here is that the AppleScript hooks in the Finder can’t cope with FileVault. I tried programming an Automator Action based on Jan Bardi‘s AppleScript, but the resulting alias still causes these errors.
The only workarounds are to move files into a working directory and then move them back, or to turn FileVault off. I did the former.
To do this in a workflow:
1. Create a folder somewhere outside of FileVault (I created a “Scratch” folder on my startup disk)
2. Use either the “Copy Finder Items” or “Move Finder Items” Finder Action near the start of your workflow and set the folder in step 1. as the destination.
3. At the end of your workflow, use the “Move Finder Items” Finder Action and you can set your destination back in a FileVault folder.
You probably want to check the “Replacing existing files” checkbox in both of these Finder Actions.
Now your workflow can cope with FileVault, though not securely. A malicious program might monitor such working folders and copy their contents elsewhere, but if it’s going to a be a workflow running on a private machine, it’s most likely safe.