Lion, Acorn, and Transmit Disk

When I saw that Gus Mueller had written a post about potential pitfalls in using Lion’s new versioning and autosave features, I hoped it might touch on a problem I’d had involving his Acorn image editor and Panic’s Transmit file transfer application. No such luck, but it was a good post.

The problem Gus posits is one in which a user makes a minor addition to an image, copies it, and pastes the image into an email. There’s no intent to save the changed image; the addition is just for the email. But when the user switches away from the image editor to the email client, the changed image gets autosaved, disregarding the user’s intent and overwriting the original file.

Now, you might say this is a contrived example, but I’ll bet you could come up with your own examples where you’ve taken advantage of the fact that your system does not autosave. I don’t think these examples constitute a good argument against autosave—and Gus certainly doesn’t want his example to be taken that way—but they do show how those of us with years (decades, in my case) of experience without autosave will have to recalibrate our expectations to fit the new world with it.

So as I said, a thought-provoking article but not one that addressed the problem I had had.

My problem came when I wanted to make a minor edit to a PNG file on my site. I opened a connection to the site using Transmit Disk, the feature that mounts a remote directory on your system as if it were an external disk. Then I opened the PNG file in Acorn, did the edits, and saved. When I hit ⌘S, I got one of those “Another application has changed this file. Do you still want to save?” warnings. I clicked the button that said I did want to save and then reloaded the web page to see the newly-changed image in context.

And got the “not found” placeholder instead of the PNG.

This is supposed to be this way

This happened first with Acorn 3.1 (which I believe had autosave turned on by default) and more recently with Acorn 3.1.1 (which doesn’t). Transmit 4.1.7 in both cases.

Is this a problem with Acorn, Transmit Disk, or Lion itself? I don’t know, but here’s what I do know:

  1. I don’t get this problem with text files when the remote directory is mounted with Transmit Disk and I edit the remote files with TextMate, an application which is, it’s safe to say, not Lion-savvy.
  2. I don’t get this problem with image files when the remote directory is accessed via SFTP through the normal Transmit app and I edit the remote image file in Acorn.

I’m not sure who to report this problem to, Panic or Flying Meat (reporting it to Apple strikes me as a waste of time). I suppose I’ll just excerpt this post and send it off to both of them to see what they think. In the meantime, I have the workaround of using Transmit proper instead of Transmit Disk.

Update 9/24/11
Following the advice of Gus Mueller in the comments, I mounted the remote directory with Transmit Disk, opened the PNG in Preview, edited it and saved, then refreshed the web page that used the image. I did not get the “image not found” placeholder, but I did notice that the Finder window showed two copies of the image file in the mounted directory. An ls -l from the Terminal showed only one copy, though.

Further intrigue: I then returned to the original version of the file using the Time Machine-like interface that came up when I used Preview’s Revert to Saved… command and went through the same series of steps a second time. Everything went the same way except this time the Finder didn’t show a second copy of the file.

Emboldened, I opened and edited the file in Acorn, saved it, and refreshed the web page. This time the edited image appeared—no placeholder.

At this point, I can think of two possibilities:

  1. I’m an unreliable witness and nothing I say can be trusted.
  2. The network lag may be showing me things that aren’t real because the various saves and updates are lagging a bit.

I hope it’s the latter.

In any event, I appreciate Gus’s comments and suggestions. I’m going to keep playing around with this until I have some repeatable results that I understand.

7 Responses to “Lion, Acorn, and Transmit Disk”

  1. Wuffers says:

    Personally, I think you should report to Panic. It seems to me like it’s an issue with Transmit making Acorn think it had edited the file.

  2. Jamie says:

    I will bet you it is Transmit’s “fault”. Not that they are to blame - they told us the disk function doesn’t quite work yet. But I bet you it flushes a write before Acorn finishes up whatever it is up to.

  3. Gus Mueller says:

    You could also try using another app to rule out Acorn - try using for instance. Add a line or something, then see what happens.

    That error message sounds like something the system frameworks would cough up. I bet preview will do the same thing.

  4. Gus Mueller says:

    Also- 3.1 did not have autosave turned on by default. There were only a couple of betas where this was the case- no release versions.

  5. Dr. Drang says:

    Thanks for the suggestions, Gus. I’ve updated the post with my experience with Preview. And I misread the part about the autosave default.

  6. Ryan says:

    This happens to me every so often while editing a text file located in a Dropbox folder with Textmate’s ‘save on blur’ feature (still on Snow Leopard). Still haven’t figured out the exact timing to reproduce it reliably.

  7. Clark says:

    I think we’ll find we make duplicates more often with the Duplicate command. I’m already getting in the habit of it. Unfortunately the System doesn’t assign a default shortcut to it (but we should).

    I do a lot of minor changes to common files that I used to save. However I found it was really easy to accidentally save my changes without being aware of it which would cause troubles a week later. With the new Duplicate workflow that just doesn’t happen.

    I can’t say I’m used to the changes to Pages and Numbers yet, although I’m already missing it in Excel. Ultimately I think the new system better but it’ll take a long time for everyone to adjust their habits.