Fixing a corrupted AppleScript file

Recently I had a problem with some AppleScript .scpt files being somehow corrupted such that opening them in a script editor (Apple’s or Late Night Software’s Script Debugger) rendered them as ‘garbage’ instead of a readable script. Actually, it appeared to be the compiled code being rendered as plain text: button labels, text properties, etc. were readable, but the commands, keywords, etc were not.

The key to identifying this situation is that the characters “FasdUAS ” appear near the top of the text.

Using Spotlight to view the file showed the script correctly, so I knew the information to recover it was ‘in there’ somewhere. But the Spotlight window provides no way to copy the data (jn 10.10 at least, which is where I am).

The solution to recovering these files is a bit bizarre: use Spotlight to ‘find’ the file, and copy the compiled script from the preview in that window. Paste that into a new script, recompile, and save.

Note: my first thought was to paste the text back into the corrupted script and compile that, so I wouldn’t have multiple files floating around. That seemed to work except that reopening the file opened as text, requiring a recompile each time. Clearly there’s something about the file that thinks it is plain text (probably .applescript) and finding that might be the key to repairing the original file.

But that’s a task for another day.

Moving Time Machine Backup Sparsebundles

So I was wondering: can I move a Time Machine sparsebundle file from one location to another and have Time Machine accept it without complaint?

Short answer: yes.

Long answer: follow these steps:

  1. On the source machine, turn off Time Machine.
  2. On the Time Machine Server, move the sparsebundle to its new location.
  3. On the Time Machine Server, make sure the new location is a valid Time Machine backup destination.
  4. On the source machine, turn on Time Machine.


Fixing the eppc protocol

When Apple released Security Update 2015-002 ( they included a fix for the “FREAK” exploit. Unfortunately, that fix broke the eppc protocol. Fortunately, they fixed it in a subsequent patch for Mavericks. Unfortunately, for Lion/Mountain Lion you have to download a separate patch at Fortunately, it’s an easy patch. Unfortunately, Apple never released a similar patch for Snow Leopard. Fortunately, somebody else did. Unfortunately, I can’t remember who. Fortunately, I still have it and you can get it here.

See also this MacScripter Discussion.

Using GUI apps with Apache

For a project I am working on, I need Apache to be able to access an application running in the user’s GUI. The safest (I think) thing to do is to add that user to the _www group, like this:

sudo dseditgroup -o edit -a `whoami` -t user _www

(Replace `whoami` with an actual username, if you want to get specific.)

Activating server-status, what I didn’t realize

Turning on server-status (and server-inf0) lets you keep an eye on your Apache server’s activity, etc. The docs I ran across said simply to enable:

LoadModule status_module libexec/apache2/

But that’s not the whole story. You’ve also got to add some directives to httpd.conf:

ExtendedStatus On

“ExtendedStatus” is optional, but it provides more info. The next part is required:

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    #Allow from all
    Deny from all
    Allow from #autsys

This instructs Apache to respond to /server-status by generating… the server status! You might want to change the location to something more opaque (like: s-stat) if you are worried about snoopers.

You can also get a lot of information by activating server-info:

# Added by MRS 2010MAR19
<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from #autsys

Notice also the aggressive permissions: start by denying all access and then allowing only your IP address or address range. If you don’t have a fixed IP address, you maybe shouldn’t be doing this, eh?