Export script doesn't work anymore in Sierra 10.12.2 [fixed in Sierra 10.12.4, or see thread for workaround]

Previously, I had a script that would export an outline to various formats. It can be seen in this discussion here… I can’t get OmniOutliner to export a text file

If I run it from Script Editor, I get the following error:

error "OmniOutliner got an error: “crud.rtf” couldn’t be moved because you don’t have permission to access “Desktop”." number 7

If I run it from within OO4, from the Mac’s script menu, it doesn’t generate an error, but then it does nothing at all. The gear icon appears for a second and then goes away. No new file is created.

FWIW, when I wrote the script, I was running 10.11, but I now run 10.12. This is the only situation I’ve encountered where I get this type of permission error.

I’ve seen references to similar error types here but no solution. Any ideas?

This appears to be an AppleScript sandboxing bug in 10.12.2 and 10.12.3 which has apparently been fixed in the beta releases of 10.12.4. It affects all scriptable sandboxed apps, including built-in apps like TextEdit, and the issue is with scripts failing to grant access to create files that don’t exist yet.

The workaround is to create the file from the script first, like so:

close access (open for access myFile)

So, with that workaround applied, your whole export script ends up looking like this:

tell application "OmniOutliner"
	
	--Export to the desktop, using the current filename (sans extension)
	set deskPath to path to desktop folder as string
	set fileN to name of document 1 as string
	
	--Combine path and filename
	set DeskSave to deskPath & fileN
	
	--As export only affects visible text, expand all so that entire doc is exported
	expandAll
	
	--Export as three different doc types and append the appropriate extension
	close access (open for access file (DeskSave & ".opml"))
	export document 1 to file (DeskSave & ".opml") as "org.opml.opml"
	close access (open for access file (DeskSave & ".txt"))
	export document 1 to file (DeskSave & ".txt") as "public.plain-text"
	close access (open for access file (DeskSave & ".rtf"))
	export document 1 to file (DeskSave & ".rtf") as "public.rtf"
	
end tell

Hope this helps!

3 Likes

Thank you. That fixed it perfectly. Much appreciated.

Out of curiosity, where does this ‘close access’ come from? It isn’t in the dictionary for OO4.

It’s from the StandardAdditions OSAX (scripting addition)

1 Like

Thanks for the info. I ended up checking out the Language Guide to get an understanding of the commands. So the fix above makes a bit more sense to me now.

I have an applescript I’ve used for years to convert OO files to LaTeX in a fancy way. After updating to macOS 10.12.4, I’m having permission problems.

The above workaround didn’t work for me.

Is anyone else having this problem, or is there a known fix? Wading into the marsh of Applescript is always a bit buggy.

Here are the details:

This line of code

export theDoc to theOPML as "org.opml.opml"

is now tripping the error

error "OmniOutliner got an error: “syntax-outline-swv.opml” couldn’t be removed because you don’t have permission to access it." number 7

Note that theDoc and theOPML are variables holding the name of the frontmost document and the name of the resulting OPML file I’d like.

I tried using the fix of opening and then closing the access to the file as given above, only to get a different error

error "OmniOutliner got an error: Network file permission error." number -5000 from file "/Volumes/Shuttle/Training/Lessons/020syntax/syntax-outline-swv.opml" to «class fsrf»

The ‘Network’ error is bogus, because copying the file from a disk image to my Desktop gives the same error.

An update:

The Network error in my post was due to my complete inability to figure out when Applescript can handle POSIX paths, when it needs aliases and when it uses its own files references.

The variable theOPML in my post referred to the file as a POSIX path rather than what AppleScript thinks is a file. So… I changed it to

close access (open for access ((theOPML as POSIX file) as alias))

The bit about ‘as alias’ at the end is because I had bad past experience with properties of scripts being changed if file names were set as non-aliases.

Ken’s workaround did work (even for an already-existing file). Sorry for the static.