FileVault issues with automating workflows on the Finder selection

[Jan]

A while back, I posted the script “FileVault-proof Finder selection to alias list” in the “Scriptbuilders” forum and received the question below on integrating it in Automator. My attempt at a reply is below, tough I’m sure it’s not the final word. Any better ideas, anyone?

Thx,

Jan

Hello,

I am a bit confused on how to use this
script. What i am trying to do is use
automator to grab a list of photos from
finder, then pass the list to preview to
scale the photos. Like yourself i run
filevault and get the dreaded -1728
error whenever i try the scripts. Do i
just put this after the get finder items
automator action in a run apple script action?

Thanks

marc

Essentially yes, tough you may have to play around with replacing the finderSelectionToAliasList() handler in the run block with f.i. the also included finderSelectionToPOsixPathList() handler, as I believe the Preview application prefers to accept a list of posix paths as input in Automator workflows.

In workflows that you call from within f.i. Automator, you don’t need the “get selected finder items” step at all, just put the run apple script action step discussed above in its place to avoid FileVault issues.

In case you plan to save the workflow as a Finder plugin, I believe that you might also not need the apple script step - in Finder plugins, Automator sometimes seems to treat selected FileVault items correctly, i.e. as a regular Finder items selection. In this case, just make sure not to insert a “get selected finder items” step at the start of your workflow: it appears that explicitly calling the Finder action will often ruin things again. (Used in a plugin, a FileVault-friendly version of the “get selected Finder items” action seems to be called automatically most of the time…)

Sorry for this “trial & error” reply, but I haven’t fully explored all the FileVault issues in Automator myself. In case you really get bogged down in Automator, perhaps you can fall back on Script Editor instead of Automator and script a regular AppleScript droplet - they also automatically bypass the Finder issues with selections of FileVault items. In this approach, you might prefer to use Image Events scripting to scale your pictures instead of calling the Preview application. Browse the “Scriptbuilders” and other forums here for other scripters’ approaches on automating/scripting repetitive image scaling.

HTH,

Jan

Model: Alu-PowerBook 15" 1.25 GHz
AppleScript: 1.10
Browser: Safari 412.2
Operating System: Mac OS X (10.4)

[Conrad]

Hi Jan,

I looked into converting your script into an Automator Action. The aliases returned by your script are incomplete. For example, the file type can not be returned for any of the aliases it generates.

[Jan]

Lets check.

Insert the line “info for item 1 of result” at the end of the run block in my script:

on run
finderSelectionToAliasList() – converts the Finder selection into a list of aliases, even when they’re FileVault-protected
info for item 1 of result
end run

For a selected file named “index.htm” on the desktop of my FileVault-protected home folder, this returns:

{name:“index.htm”, creation date:date “maandag, 6 januari 2003 14:10:47”, modification date:date “maandag, 13 juni 2005 09:38:31”, icon position:{0, 0}, size:2868.0, folder:false, alias:false, package folder:false, visible:true, extension hidden:false, name extension:“htm”, displayed name:“index.htm”, default application:alias “myStartupDisk:Applications:Tex-Edit Plus 4.8.2:Tex-Edit Plus.app:”, kind:“Tex-Edit Document”, file type:“TEXT”, file creator:“TBB6”, type identifier:“public.html”, locked:false, busy status:false, short version:“”, long version:“”}.

Notice the “file type” record item. After moving the file outside the FileVault-protected home folder, it returns a similar result, still including the “file type”. Removing the .htm name extension doesn’t affect the outcome either: the “file type” is still there.

In short, I can’t reproduce your finding on my system. My best guess is that you tried to access the “file type” as an item property via the Finder:

tell application “Finder” to get file type of (anyFileVaultItemAsAlias) – instead of “get file type of” use “get properties of” to see all Finder item properties

This errors out. AppleScript’s buggy FileVault implementation prevents the Finder from accessing any regular Finder item property for FileVault-protected items, including “file type”. My script coerces selected FileVault items into aliases, another thing we can’t script the Finder to do due to these bugs. But getting to the alias stage does allow you to call the “info for” command, that luckily also bypasses the Finder and returns many of the Finder’s regular item properties (but not all, unfortunately: you’ll have to do without useful properties like “URL” and “creator type”).

Coming back to integrating the script in Automator: if your workflow requires you to access a FileVault item’s Finder property directly, you may be in trouble. You could consider adding a further AppleScript step calling the “info for” command, if the information record returned contains the property needed. Also take into account that in my experience, Automator appears to rely on posix paths rather than on aliases. Adapt the script as indicated in my original post to have it return posix paths instead of aliases.

HTH,

Jan

Model: Alu-PowerBook 15" 1.25 GHz
AppleScript: 1.10
Browser: Safari 412.2
Operating System: Mac OS X (10.4.2)

[Conrad]

Sorry, still a no go as far as I can tell. Here’s a test workflow:
get a FInder item (pick an image)
Copy to the Desktop
run an Applescript, and use this one, with the following in the on run method

on run {input, parameters}
	return aliasListToPosixPathList(finderDocListToAliasList(input))
end run

Then pass the resulting alias to Scale Images

It still won’t be able to get the file type I’m afraid.

[Jan]

OK, got it, I think. The Automator workflow I’ve come up with achieves what you want, albeit via an excursion outside your FileVault-protected home folder. But first the learnings. You have 2 FileVault-related problems as far as my tests show:

1. You try to use the Automator action “Scale images” in Preview to process the image copies, but this action fails to save the scaled image files back into a FileVault-protected location like your Desktop. That’s where Automator throws up the error message “Can’t get file type of file…” you mention. One more sample of buggy FileVault implementation, I’m afraid.

2. You try to use the Automator action “Copy Finder items” to copy your images to the desktop in the beginning of your workflow. But this action refuses to accept FileVault-items as input in the way it accepts regular Finder items.

To solve the first issue, I propose you don’t copy the image copies into a FileVault-protected spot like the desktop, but f.i. in a folder outside your protected home folder. In the workflow I’ve come up with, I use a folder in the “Shared” directory. After Preview has scaled and then saved the image copies there, you just move them back to wherever you want inside your protected home folder, like f.i. your desktop, by using Automator’s “Move Finder items” action.

The second issue is fixed via my script as mentioned above. Use it to coerce your image file input into a list of posix paths - that’s an input type Automator’s action “Copy Finder items” does accept, even for FileVault-protected items.

I’ve posted my sample workflow at

http://homepage.mac.com/janbardi/.Pictures/scale_pix.zip

on .Mac; download it and have a look at how things work. It’s not the most elegant workflow ever, but it does the job on my system. Adapt the necessary settings, like in what folder outside your home folder you want the image copies to be processed and where on your home folder you want the scaled results moved back to. To watch it run:

1. open the workflow in Automator;
2. select the image files you want to scale in the Finder;
3. command-tab back to Automator and run the workflow.

HTH,

Jan

Model: Alu-PowerBook 15" 1.25 GHz
AppleScript: 1.10
Browser: Safari 412.2
Operating System: Mac OS X (10.4)

[Conrad]

Thanks Jan,

Actually I did the same thing. I just made a working directory outside of FileVault for all file processing. Kind of a pain, but what we have to do for the time being until Apple patches this bug.

Thanks again for all the help and hard work.

best,
Conrad

[Jan]

To alleviate the security concerns you may have about processing items containing confidential data outside your FileVault-protected home folder, consider the following workaround:

As buggy as the current FileVault implementation appears in both Automator and the scriptable Finder, its problems paradoxically don’t extend to other types of encrypted volumes. This means you can set the processing to take place in a folder whose data safely reside in an encrypted disk image INSIDE the FileVault-protected home folder! Bizarre, but true.

Steps to securely set this up:

1. use f.i. Apple’s disk utility to create a new encrypted disk image, named f.i. “tempAutomator”;
2. save/move it somewhere inside your FileVault-protected home folder;
3. double-click the disk image in the Finder to mount its volume;
4. navigate to that volume in the Finder and create a new folder in it, named f.i. “AutomatorVault”;
5. outside the volume of your disk image “tempAutomator”, make a Finder alias “AutomatorVault alias” of the folder;
6. in the run block of the “Run AppleScript” step at the beginning of the Automator workflow, insert a line

tell app “Finder” to open alias text_path_to_AutomatorVault_alias

to launch the alias “AutomatorVault alias” and mount the disk image “tempAutomator” at the start of the workflow;
6) still in Automator, set the folder “AutomatorVault” as the target of the “Copy Finder items” step in your workflow;
7) finally, add a “Run AppleScript” step at the end of the Automator workflow with the code:

tell application “Finder” to eject disk “tempAutomator”

to automatically unmount the encrypted disk image at the end of the process.

The workflow now both opens and closes the encrypted disk image containing the processing folder automatically, a situation nearly as secure as the FileVault protection itself. If like me you rely on Keychain to store and manage your passwords, have the disk image’s password stored in Keychain and you won’t have to enter it manually every time you run the workflow. That way, the speed hit to pay for the better security is just the time it takes to mount and unmount the disk image containing only 1 empty folder every time the workflow runs.

HTH,

Jan

[Jan]

Just posted update 1.2 of my “FileVault-proof Finder selection to alias list” script in the “ScriptBuilders” site at

http://scriptbuilders.net/files/filevaultprooffinderselectiontoaliaslist1.2.html

with a code cleanup of the crucial finderDocToAlias handler and some tutorial comments. For FileVault-proof Automator workflows with the Finder selection as input, also see the sample code in the thread Finder: FileVault-proof “Get selected Finder items” at

http://bbs.applescript.net/viewtopic.php?pid=49383

in the Automator Scriptlets forum.

HTH,

Jan

[Jan]

I’m a novice at scripting. I’m using scripts someone else wrote. My company’s IT department put FileVault on all systems and now my scripts won’t work. I’m sure one of your scripts will solve my problem but I don’t know what to do with your script. Do I insert it at the beginning of my script? Where do exactly would I place your script. I need help.

Nancy

Dear Nancy,

Don’t we all?

However, more specifically: whether and how my script can help you depends on several factors:

• How did you trigger your scripts before FileVault was activated on your system? If you used to drag and drop files onto the script applet’s icon to run the script, it’s likely the FileVault-related problems are buried well into the script code. In that case, integrating my script might become a case by case problem and even then not be sufficient in its own right to solve your issue. If you ran the script from the script menu or from within the Script Editor application, your chances for a straightforward integration of my script are better.

• Does your script also stumble on another FileVault-related AppleScript bug, that my humble script wasn’t designed for and hence can’t tackle? AppleScript’s issues with FileVault are widespread, diverse and not limited to scripting the Finder selection.

• Were your scripts saved as “run only” or do they still appear as editable when opened in Script Editor? If they’re “run only”, you can’t modify them. To fix that, you’ll probably need additional scripts to run before and possibly also after your originals (see below).

First, consider a simple, straightforward fix for editable versions of basic scripts run from the systemwide AppleScript menu or from within the Script Editor. Paste the following code at the script’s end:

script finderSelectionToAliasList
	
	on run
		finderDocListToAliasList(finderSelection())
	end run
	
	on finderSelection()
		tell application "Finder" to get selection
	end finderSelection
	
	on finderDocListToAliasList(finderDocList)
		set aliasList to {}
		repeat with i in finderDocList
			set end of aliasList to finderDocToAlias(i)
		end repeat
		aliasList
	end finderDocListToAliasList
	
	on finderDocToAlias(finderDoc)
		try
			tell application "Finder" to get finderDoc as alias
		on error errormsg
			set markerString to "xyzabazyx"
			repeat while errormsg contains markerString
				set markerString to markerString & markerString
			end repeat
			set oldTIDs to AppleScript's text item delimiters
			set AppleScript's text item delimiters to {"\\\""}
			set theLst to text items of errormsg
			set AppleScript's text item delimiters to {markerString}
			set messageWithoutQuotes to theLst as string
			set AppleScript's text item delimiters to {"\""}
			set theLst to text items of messageWithoutQuotes
			set idCounter to 1
			repeat with i in (items 2 thru -4 of theLst)
				if idCounter is 1 then
					set idCounter to 0
					try
						set pathString to i & ":" & pathString
					on error
						set pathString to i
					end try
				else
					set idCounter to 1
				end if
			end repeat
			set AppleScript's text item delimiters to {markerString}
			set theLst to text items of pathString
			set AppleScript's text item delimiters to {"\""}
			set pathString to theLst as string
			set AppleScript's text item delimiters to oldTIDs
			try
				alias pathString
			on error
				alias (pathString & ":")
			end try
		end try
	end finderDocToAlias
	
end script

This is just a condensed, standalone version without comments of my script. Now check if your script tries to convert the Finder selection into a list of AppleScript aliases at some point. If so, replace the relevant parts of that code with the line below:

run script finderSelectionToAliasList

If this makes your script run again, consider yourself lucky: it only ran into FileVault-related AppleScript bugs at that single point. If not, the most obvious solution - apart from debugging problem by problem manually from script after script - is to write a precursor droplet, that basically copies items dropped onto it to a directory outside your FileVault-protected home folder and then selects the copies instead of the originals. The droplet below duplicates dropped items into the “Shared” folder and then selects the copies:

-- Save this code AS AN APPLICATION to create the precursor droplet.
-- Then switch to the Finder and drop some items from anywhere in your home folder onto the droplet's icon to see how it runs.  

on open (docList)
	
	set targetFolder to alias (((path to (users folder)) as string) & "Shared:")
	
	tell application "Finder"
		duplicate docList to targetFolder
		select result
	end tell
	
end open

Then you should be able to run your original scripts on those copies, as they now reside outside the FileVault-encrypted part of your system. Don’t forget to remove them from the Shared directory after you’re done - trash them or move them back into your home folder depending on what you need (this part is a good candidate for being automated via an additional closing script). For a similar workaround with Automator workflows, refer to “caveat nr. 2” in the introductory comments at

http://bbs.applescript.net/viewtopic.php?pid=49383

in the Automator Scriptlets section at MacScripter.net.

You may need to discuss the best target location for your duplicates with your IT people, because once outside your home folder, the copies are basically accessible to all other users on your system - a potential security breach depending on your exact system layout and the type of work you try to automate. Or point them to the secure workaround I posted at

http://bbs.applescript.net/viewtopic.php?pid=43788#p43788

earlier in this thread.

HTH,

Jan

Model: Alu-PowerBook 15" 1.25 GHz
AppleScript: 1.10
Browser: Safari 416.13
Operating System: Mac OS X (10.4)

[Jan]

No more need for these workarounds in Leopard, Apple finally fixed the underlying bug when moving to Mac OS 10.5.