September 23rd, 2011 at 9:44 pm by Dr. Drang
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 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:
- 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.
- 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.
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:
- I’m an unreliable witness and nothing I say can be trusted.
- 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.