OS X Mountain Lion: Data Loss via 'Save As'

Also, if you send the file to someone they get the latest changes, they don't get any history... the history is snapshots made by the OS much like Time Machine does for backups, except it is done every so often automatically (auto save) and not to an external drive.

The only real cock-up is the Save As. Save As should save the new file, and revert the old file back to what it originally was (the last time I explicitly saved, not the spot that auto save last saved).

If you want to modify a copy of the file, before you start your modifications you simply choose File -> Duplicate and it opens the same document but with a different name. When you save that one it will have an entirely new history associated with it.

The fact that it is a file system feature that is baked into the OS means that all apps can take advantage of it if they want and the overhead is small. It also means that apps no longer need to keep notes about what modifications were done to what, instead being able to rely on the auto save feature. The other nice thing is that since it is not part of the document and is outside of it, data leakage is much less of an issue than with other file formats such as Microsoft Word where recovering previous text is rather simple and can lead to data leaking that you wouldn't want leaking.

Why is this bad?

edit: Why are people downvoting me for asking this question? I'm genuinely curious.

Anyhow, ML isn't doing a "save" and "save as..." now; it had already done the "save" part. Apple really should do a better job explaining this, but it's most likely not consistent across all apps. Does XCode even do this now?

It reminds me of the preferences behavior where you make your changes and that's it, rather than requiring you to hit an "OK" or "Apply" button as in Windows.

Versioning (and allowing reverts) is awesome, but changing a decades-old idiom to something that suddenly destroys data is...well, scary, to say the least.

Edit: Someone further down the thread suggested that the function be renamed to "Duplicate and Save". That would totally fix the problem - this is a new interaction mechanism, totally different from what we've all been training on for the last thirty years, and it needs a new name. The feature itself is fine, but hijacking an existing operation's name for it is not cool. It violates the principle of least surprise.

Here is an analogy one could one make to the current implementation -- you request to be billed later, but instead the full amount is deducted from your bank account now, and you are also sent another bill in the mail a week later, which you pay because you didn't know you already paid for it.

Something makes me think that there are a lot of giant egos at Apple now, making eccentric decisions, and Steve Jobs isn't around to tell them they are stupid.

The real end goal here is for Apple to somehow figure out a way for the average person to have the power of modern version control while still understanding it. This is a good goal, and we should laude Apple for it.

Let me give one example - I sometimes want to read the content of the file (inside its own app), maybe make some changes and then Save As a new version. I do this mostly in MS Word (for Mac and thankfully they haven't gotten rid of Save As yet). We keep different version in different files, especially for our team. Updating the original file by default is simply stupid in my case.

I used to do what you describe--open the original, make changes, then Save As. Until I accidentally hit Save instead of Save As. Goodbye original.

Now when I want to work off an original I make a copy of it first in the filesystem, then open the copy with the application (Photoshop usually). Since I never open the original with the app, I can't screw it up. I don't have Mountain Lion yet but the "Duplicate" functionality sounds like it will work for me.

Thats why a smart entrepeneur developed the eraser.

And this is why I think it's broken. There are times when I don't know ahead of time if I want to keep the edits in the document I've worked on, or 'fork' it and give it a completely separate name. Making me decide up front is forcing me to do more of the work instead of the computer, which is not how it should be.

I will probably bite the bullet and upgrade to ML this year - still on Snow Leopard right now, because I really don't like these sorts of mental model changes.

They're leaving state management up to the end user which is almost always a bad idea.

Yes it does. In my real life, the computers I have been using most of my life had the concept of unsaved changes.

This reasoning is ridiculous. I don't want my computer to behave like some other thing, including arbitrary limitations. I want it to implement the features of a computer, constrained only by the limitations of a computer.

"You can't do X because this other old fashioned thing you never use nowadays couldn't do X in the old days" is a pretty piss poor excuse.

There's nothing wrong with new standards. This might in fact be an excellent way to do things.

The problem is giving new, completely different standards the same name as old standards. "Normal" non-tech people would be just fine with this feature if you named it something different like "save and duplicate" -- and tech people wouldn't be caught off guard by the system misusing common tech terminology to mean something totally different.

-(void)dataChanged { [document writeToFile:fileName]; }

  switch (menuEvent) {
    case FILE_SAVE_AS:
       NSDocument newDocument = [initWithDocument:oldDocument]
       [newDocument writeToFile:newFileName];

  git branch new-branch
  git reset -hard <startpoint>

Just to make it clear, the linked blog post is wrong; there is no data loss in this situation. All that happens is one more save point, which does not harm earlier save points. (aka versions)

In Lion/ML, if you create a new file, Save it with a name, and afterwards add some text and then close the window, it doesn't prompt you to "save changes", since it's always saving changes. In a model like that, there's no reason for "Save As" to suddenly not save changes in the original window.

But you want to keep it "in memory" while you experiment with it. The new model is more natural: if you paint on a canvas, it's painted. If you want to experiment, use the magical canvas duplicator and work on that copy, then just throw it away if you don't want to keep it.

That said, they shouldn't have brought Save As back. Imposing a new model is already upsetting, making old functionality behave differently is terrible.

I think to advance to the world of auto-save, one also needs to much more visibly advance to the world of file versioning where it's really clear to the user whether their changes are ultimately destructive or not.