OS X Mountain Lion: Data Loss via 'Save As'(macperformanceguide.com)
macperformanceguide.com
OS X Mountain Lion: Data Loss via 'Save As'
http://macperformanceguide.com/MountainLion-SaveAs-data-destruction.html
153 comments
The version history is stored by the file system and not by the file itself. If you copy the document you don't store any of the version history and you can't revert (from my experience).
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.
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.
> 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.
I think one of the biggest issues I take with it is that by making it a part of the document editor itself, you make it seem (to the user) as if it's a feature of the application/format, and not a feature of the operating system that has just been integrated into the application. Without any other sort of explanation the user will probably assume that this is all stored in the document, and be in for a surprize when they copy it somewhere else, and the history disappears.
> An entirely new history? Doesn't that kind of suck? It would be preferable to have the copy also retain history prior to duplication.
> It also means it is non-portable, and you can lose this history when backing things up (unless you only use Time Machine for backups presumably).
Yes, it is non-portable. For those apps where that is an issue there is always the choice of baking it into the file format itself.
As for backing it up, you are able to back-up /.DocumentRevisions-V100/ along with everything else you back-up. This is where auto-save saves the files, and its various versions.
> I'll agree with this. Maybe the middle ground is something similar to OS X's metadata dot-files (i.e. ._.filename).
As for better user education on Versions, I'll agree with that one hundred percent. The functionality is provided free of charge to developers using NSDocument (from reading other peoples threads on this HN thread) and thus does require some help from the program, if they read/write using POSIX they won't get free support for it.
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.
What if you only decide that you want to save as a different file after you are half way through your modifications?
What if you only decide that you want to save as a different file after you are half way through your modifications?
Hit File -> Duplicate ... save the new copy as a different file name, in the original File -> Revert -> Last Opened. Now your Duplicate contains all of the new stuff, and your old file contains all of the old stuff.
Duplicate and Revert Original should be an option, unfortunately it isn't.
Duplicate and Revert Original should be an option, unfortunately it isn't.
When you choose Duplicate on an edited file, you're given the option to Duplicate and Revert the original file. Handy.
That's how it worked in Lion, but Mountain Lion behaves differently -- you get the duplicate with its file name selected, so you can rename it, but the original stays modified unless you think to immediately pick "Revert to last saved version".
I actually liked the Lion behavior better. (Now I wish I'd had the chance to try out the Mountain Lion beta before release, so I could have filed a bug for this.) That's what we get for everyone complaining about the lack of "Save As"...
I actually liked the Lion behavior better. (Now I wish I'd had the chance to try out the Mountain Lion beta before release, so I could have filed a bug for this.) That's what we get for everyone complaining about the lack of "Save As"...
That is not the case, at least not with TextEdit ... when you choose Duplicate you get two files with the same contents.
You can then save the duplicate as you wish, and revert the old one back to when it was opened using File -> Revert -> Last Open.
You can then save the duplicate as you wish, and revert the old one back to when it was opened using File -> Revert -> Last Open.
File -> Rename/Move File ?
Yeah, I noticed this one too, when cropping a picture and saving it as a new file (in Preview). Both the original and the new one were cropped. A moment of panic later, and I found the revert option in Preview, but only because I knew it existed.
Totally. 100%. Undesirable. I did not Save. I saved to a new file. The only option now appears to be duplicating before editing (bad) or hoping the application has an 'export' option which sidesteps this (also bad - export typically presents far more options than save-as).
Totally. 100%. Undesirable. I did not Save. I saved to a new file. The only option now appears to be duplicating before editing (bad) or hoping the application has an 'export' option which sidesteps this (also bad - export typically presents far more options than save-as).
> duplicating before editing (bad)
Why is this bad?
edit: Why are people downvoting me for asking this question? I'm genuinely curious.
Why is this bad?
edit: Why are people downvoting me for asking this question? I'm genuinely curious.
Because it's a horrible UX paradigm to require. If 'Save As...' had never existed, it wouldn't be unreasonable, but it is (was) a reasonable behavior that every other system I'm aware of has maintained.
This passive versioning thing is quite nice in some aspects, but it's very unknown with most people I've seen. They see a file changed, they assume it's stuck like that now and the original is gone forever. Why would they expect otherwise? Their unsaved file gave no indication of being saved. Every application they open it in, and everyone they email it to, will only get the most-recent version. Even the file-system doesn't tell you when you have multiple versions of something.
This passive versioning thing is quite nice in some aspects, but it's very unknown with most people I've seen. They see a file changed, they assume it's stuck like that now and the original is gone forever. Why would they expect otherwise? Their unsaved file gave no indication of being saved. Every application they open it in, and everyone they email it to, will only get the most-recent version. Even the file-system doesn't tell you when you have multiple versions of something.
I see it as part of the iOSification of OS X, to appeal to iPad/iPhone halo converts. My phone has never asked me if I want to "Save changes".
I like the feature, to be clear. I just think it's horribly executed, and the education side has been even worse.
The problem is that they took something. Then they changed it, giving it multiple nearly-invisible modes it can be in, which changes from application to application (not all have a 'revert' option, even for versioned files). Then they didn't tell anyone.
For instance. I just cropped this file. How do I know the original still exists? http://cl.ly/image/2L2X0x042W0N
Here, I opened it in another application. Are there multiple versions? http://cl.ly/image/3Y1m3C2r1r2f
What about in the File menu? http://cl.ly/image/0F2o2H2i3Z2f
Finder? http://cl.ly/image/1C0S3z3Z0q30 or http://cl.ly/image/463p0O1I3q1C or http://cl.ly/image/1F191E3b3U1W ?
(edit) Oh, cool - there's a "Versions" column. Maybe that has it: http://cl.ly/image/2703273U3z2U
This is bad.
The problem is that they took something. Then they changed it, giving it multiple nearly-invisible modes it can be in, which changes from application to application (not all have a 'revert' option, even for versioned files). Then they didn't tell anyone.
For instance. I just cropped this file. How do I know the original still exists? http://cl.ly/image/2L2X0x042W0N
Here, I opened it in another application. Are there multiple versions? http://cl.ly/image/3Y1m3C2r1r2f
What about in the File menu? http://cl.ly/image/0F2o2H2i3Z2f
Finder? http://cl.ly/image/1C0S3z3Z0q30 or http://cl.ly/image/463p0O1I3q1C or http://cl.ly/image/1F191E3b3U1W ?
(edit) Oh, cool - there's a "Versions" column. Maybe that has it: http://cl.ly/image/2703273U3z2U
This is bad.
Always assume that every change you make is saved automatically, much like cutting down a physical photo.
If you still want the original photo, and another cut down version, you would use a photo copier to Duplicate the original, then cut the copy.
If you still want the original photo, and another cut down version, you would use a photo copier to Duplicate the original, then cut the copy.
"Always assume that every change you make is saved automatically" - You must have had a hard time dealing with computers until now :)
The real-world analogy makes sense, but it doesn't fit with how things have behaved. This is likely an improvement overall, but it's creating a period of upheaval and damage to people's property where better notification of the changes would make it a non-issue.
To modify and drag out the analogy to absurdity: say you previously made cropped photos by photocopying with a white rectangle mask revealing only the portions you wanted duplicated. Now, suddenly, you find that photocopying with the mask in place crops your original photo, without telling you. Nested a layer deep in the photocopier's menu is an option to undo the changes to your original.
I claim this is fine... if and only if the photocopier tells you of this before or immediately after, so you know to copy the whole thing first, and then cut, or use the 'revert' option. In a couple years that may be unnecessary, but not right now.
The real-world analogy makes sense, but it doesn't fit with how things have behaved. This is likely an improvement overall, but it's creating a period of upheaval and damage to people's property where better notification of the changes would make it a non-issue.
To modify and drag out the analogy to absurdity: say you previously made cropped photos by photocopying with a white rectangle mask revealing only the portions you wanted duplicated. Now, suddenly, you find that photocopying with the mask in place crops your original photo, without telling you. Nested a layer deep in the photocopier's menu is an option to undo the changes to your original.
I claim this is fine... if and only if the photocopier tells you of this before or immediately after, so you know to copy the whole thing first, and then cut, or use the 'revert' option. In a couple years that may be unnecessary, but not right now.
When I spent hours in a wet darkroom, I used a masking frame and the enlarger head height adjustment to crop a print, having previously marked up a work print. The negative was untouched.
The larger point I am making is that by referring to 'real' objects, we will return to a point where there is no system wide consistency any more. Case in point: editing audio tape or cine film did destroy the edited version, which is why we used prints/copy tapes.
Disclaimer: I don't use Mac OS. I do look to Apple for UI design however.
The larger point I am making is that by referring to 'real' objects, we will return to a point where there is no system wide consistency any more. Case in point: editing audio tape or cine film did destroy the edited version, which is why we used prints/copy tapes.
Disclaimer: I don't use Mac OS. I do look to Apple for UI design however.
[deleted](1)
iOS doesn't show "EDITED" next to the filename in any window title bars either. I would think most people seeing "filename.txt -- edited" in a window title bar (such as in osx 10.8 TextEdit) would assume the file has not yet been saved.
It requires me to decide whether or not I'm going to want to keep a change, before I've even started on it. Otherwise I have to plow through a big undo stack, even assuming undo is supported (and persisted) for everything I did.
There's a "Revert" menu item that reverts to the last opened state, and if you managed to close the file, there's Versions.
The change is really confusing to long time computer users. I wonder if Apple could have avoided this confusion by changing the names of "Save" and friends to something completely different.
The change is really confusing to long time computer users. I wonder if Apple could have avoided this confusion by changing the names of "Save" and friends to something completely different.
Since original the file is saved, there's nothing preventing you from closing the file. "Managing to" is as easy as closing the window with cmd-w or hitting the red dot. Previously you could say 'no' to the 'save changes' dialog that popped up reliably - now it's just gone and there's essentially no indication that you can fix it.
Look at it the other way: With the old system, if you pressed "Don't save" to that dialog by mistake, you lost everything. With the new system, it's basically impossible to lose anything (the only way is if you don't notice for long enough that the old version gets reaped).
If you know it exists. And how long until it gets reaped? (I honestly have no idea. probably long enough for it to not matter, though, I'll admit)
I'll try another way too. You had unsaved changes. You chose 'save as', which you know makes a new file. Why would you want to save the current changes to both files, ending up with two identical ones? Filename aside, they're the same file, but one can be reverted and the other can't. That's what copy/paste/duplicate is for.
edit: there are plenty of valid cases for this, but they're mostly specialty (saving stages of changes in e.g. design work). why would the average person under average use want to save-as and end up with two identical files?
I'll try another way too. You had unsaved changes. You chose 'save as', which you know makes a new file. Why would you want to save the current changes to both files, ending up with two identical ones? Filename aside, they're the same file, but one can be reverted and the other can't. That's what copy/paste/duplicate is for.
edit: there are plenty of valid cases for this, but they're mostly specialty (saving stages of changes in e.g. design work). why would the average person under average use want to save-as and end up with two identical files?
I often find myself making a base model and then iterating down different paths using saved as on the fly with no prior knowledge of the number of iterations (duplicates) I will end up with.
No idea why you were downvoted, I'm interested in learning about this too.
This behavior wasn't really introduced with "Save as..." in ML. In Lion, if you rotate a page in the middle of a PDF, then quit and reopen the file hoping to undo the rotate, it will still be rotated. Fortunately, it was someone else's presentation where I first saw this.
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.
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.
Or how about this one: you're editing an existing document and you wish to preserve the original by using "Save As" to create a duplicate when you finish editing, except at some point you hit "Command S" by accident or by reflex and you've now clobbered your original, without warning, and there's no previous version to restore.
That one's been around for 28 years, and was finally fixed in Lion and Mountain Lion.
The "Save As" command has always been dangerous and ridiculous in the way it's typically used for editing and then saving duplicates. Lion finally gives you better and more safer options, but if you're not willing to learn what those are and how it works, if you're hell bent on continuting to do it the old way, then you're not going to like it and you're going to continue to risk data loss like you have for the last 30 years.
I, for one, love the way it works. Yes, I had to sligtly change my workflow but it's change absolutely for the better.
That one's been around for 28 years, and was finally fixed in Lion and Mountain Lion.
The "Save As" command has always been dangerous and ridiculous in the way it's typically used for editing and then saving duplicates. Lion finally gives you better and more safer options, but if you're not willing to learn what those are and how it works, if you're hell bent on continuting to do it the old way, then you're not going to like it and you're going to continue to risk data loss like you have for the last 30 years.
I, for one, love the way it works. Yes, I had to sligtly change my workflow but it's change absolutely for the better.
I'm confused. All it does is make the "bad" behavior the default, but give you the option to revert it if the original file exists somewhere on disk? That's an improvement?
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.
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.
I'm not sure there was a way to introduce auto-save while maintaining the "principle of least surprise". I'm astonished, myself. I figured that, thirty years from now, we'd still be losing changes to periodic crashes of unsaved documents rather than force any customer to alter a decades-old workflow.
The problem with "Duplicate and Save" is that it implies that saving is an action that you can take, rather than something which has already happened. As arrrg said, that's not true: in Lion apps, every document which has a name is always saved. There is no longer a state of "changed but not saved".
Change the label to "Duplicate and Save" and us old folks, trained for thirty years to be constantly seeking and pressing "Save" lest we lose everything, will be complaining that there's no way to "Save" without also "Duplicating". Which would not promote understanding, either.
Don't worry, if you and the OP miss the old world of unsaved documents you can always find some old-school applications that preserve the old behavior. Join us Emacs users in the land of hoary UX paradigms! ;)
The problem with "Duplicate and Save" is that it implies that saving is an action that you can take, rather than something which has already happened. As arrrg said, that's not true: in Lion apps, every document which has a name is always saved. There is no longer a state of "changed but not saved".
Change the label to "Duplicate and Save" and us old folks, trained for thirty years to be constantly seeking and pressing "Save" lest we lose everything, will be complaining that there's no way to "Save" without also "Duplicating". Which would not promote understanding, either.
Don't worry, if you and the OP miss the old world of unsaved documents you can always find some old-school applications that preserve the old behavior. Join us Emacs users in the land of hoary UX paradigms! ;)
Sure, you can have auto-save without surprising the user. Auto-save to something that isn't the file they opened, and the commit those changes when they invoke "save". The UI itself can show whatever the latest version it has (and offer nifty things like "compare with what's saved"), but the file itself isn't written until the user asks it to be.
I'm not sure what word processing software you've been using for the past decade, but periodic backups and automatic restoration is more or less the norm, now. Heck, even my code editor persists unsaved buffers between sessions.
I think the last time I lost unsaved work in a due to a program crash was probably last millennium. That's the root of my surprise here; there are proven solutions that don't break existing workflows. Why did Apple decide to break them now?
I'm not sure what word processing software you've been using for the past decade, but periodic backups and automatic restoration is more or less the norm, now. Heck, even my code editor persists unsaved buffers between sessions.
I think the last time I lost unsaved work in a due to a program crash was probably last millennium. That's the root of my surprise here; there are proven solutions that don't break existing workflows. Why did Apple decide to break them now?
I figured that, thirty years from now, we'd still be losing changes to periodic crashes of unsaved documents rather than force any customer to alter a decades-old workflow.
Huh?
Word and Open Office have been recovering crashed documents, including unnamed, never-saved-documents, for quite a while. When that happens, it is a little confusing since you have to overwrite the existing document with the later version. But it also only occasionally happens whereas I often use the save-as functionality.
Huh?
Word and Open Office have been recovering crashed documents, including unnamed, never-saved-documents, for quite a while. When that happens, it is a little confusing since you have to overwrite the existing document with the later version. But it also only occasionally happens whereas I often use the save-as functionality.
Wouldn't it still have been better to use a different command name rather than commandeer one that has established expected behavior?
Versioning is always happening. It’s not possible for you to be not able to revert.
Also: “Save as …” is a deprecated feature (basically). You can’t even see it in the menu. There is only a keyboard shortcut for it – for those traditionalists who can’t let go. It’s not going to make the new document model worse (which is a massive improvement over the past) just to keep “Save as …” working.
Documents always save. They never not save. You can easily revert or access versions. You can easily create new versions (for example by clicking “Save” in the menu or by pressing Command+S). You can easily duplicate and immediately rename documents.
Also: “Save as …” is a deprecated feature (basically). You can’t even see it in the menu. There is only a keyboard shortcut for it – for those traditionalists who can’t let go. It’s not going to make the new document model worse (which is a massive improvement over the past) just to keep “Save as …” working.
Documents always save. They never not save. You can easily revert or access versions. You can easily create new versions (for example by clicking “Save” in the menu or by pressing Command+S). You can easily duplicate and immediately rename documents.
I agree that using the Save As command is not a good method for modifying files. However, the correct syntax for this modified should be "Save & Save As."
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.
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.
Or you can hit 'undo'. That's been around about as long as well. And since there's no file dialog, you're aware something is different, and the application is still up and running so you can make changes.
What Apple has done is changed "save as", into "fork a branch". This is progress, mostly.
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.
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.
This is not how Git, a truly professional version control system, works. In Git, you start changing files on top of the master branch, then realize you don't want to commit that to master, so you fork (checkout branch) then commit your changes elsewhere. Apple has not only ignored how-many years of simple and effective computer Save As practice. It created a not-invented-here version control system... and, as usual for NIHers of complex algorithms, Apple failed badly.
That is only possible in a distributed version control system. Apple's behavior is more similar to SVN/CVS/etc. And for sure DVCS is better and the future, but modeling their functionality after a system that's been used for decades doesn't quite qualify as NIH syndrome IMO.
That's what I was thinking about. You've got to start somewhere, and this will be accepted by aunt Tilly.
It should be noted that Google Docs also has no Save As. It does have "Make a Copy".
I completely agree. A split second of poor judgement can destroy hours of work. In this case I'm happy to let Apple save me from myself.
Reading the rest of the thread, it looks like Apple is already saving you from yourself by creating a revision each time you save. So, this change just increases the amount of work the user has to do by forcing them to go and revert the last save on the orignal document after doing a Save As.
People using "Save As" frequently don't know that they want a duplicate before they start changing things. Sometimes what I think is going to be a minor change ends up being a major change, and I want to "fork" the document.
Think of it in git terms:
I start a changeset, and after some work, find that the changeset is too big or too unstable or too hard to merge upstream. So, I `stash`, `checkout new-branch`, `stash pop`, `commit` (or just `stash && stash apply`)
This new workflow is effectively: `commit`, `checkout new-branch`. Crap, now my unstable changes are committed to my master, and to fix them and get back to what I was working on, I have to `checkout master`, `reset --hard HEAD^`, `checkout new-branch`.
It's annoying and presumptive. If git did this, there would be rioting in the e-streets.
People using "Save As" frequently don't know that they want a duplicate before they start changing things. Sometimes what I think is going to be a minor change ends up being a major change, and I want to "fork" the document.
Think of it in git terms:
I start a changeset, and after some work, find that the changeset is too big or too unstable or too hard to merge upstream. So, I `stash`, `checkout new-branch`, `stash pop`, `commit` (or just `stash && stash apply`)
This new workflow is effectively: `commit`, `checkout new-branch`. Crap, now my unstable changes are committed to my master, and to fix them and get back to what I was working on, I have to `checkout master`, `reset --hard HEAD^`, `checkout new-branch`.
It's annoying and presumptive. If git did this, there would be rioting in the e-streets.
Well, it seems it's been made even more dangerous. Why not remove it, re-label it?
Seems like there would be a better way to save the user from their occasional accidental "Cmd S" than by upending a core expectation of computer behavior since time immemorial. Why not allow the "revert" option when you hit "Cmd S"? Seems like you could keep all the same core functionality and just have a right-click accessible history of every file on disk. Is there an advantage the new system has over that?
The new system does what you suggest. Command-S creates a new "revision" in versions, and you can select "Revert to > Browse all versions" to see all versions of your document. OS X also automatically creates a new version once an hour if there are new changes.
The algorithm is actually a lot quicker to act. Once an hour would be quite useless in many cases (especially power loss).
The saving algorithm happens near-instantly, yes - but what's being referred to is the "versions" that are user-visible. Each time you hit Save, Close, or leave an edited document open for an hour, a "version" made that can be reverted to/seen in Time Machine.
I can't see why we can't have it both ways.
There's actually a very simple solution to this problem: "Save As" before you make any changes at all. Only then, in the new version, start to make your changes. Problem solved.
Pardon my rudeness here but who the hell are you to make a proclamation that "Save As" has always been "dangerous and ridiculous". Did you try that in every major workflow, like mine?
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.
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.
Welcome to the new era of client computing. In this computing epoch, we are 100% devoted to making life easier for a hypothetical 105 year old illiterate caveman who just emerged from his cave for the first time to buy a computer.
It may appear that UI designers are just working in ivory towers, pushing arbitrary and capricious changes down upon you. When you find yourself thinking that way, just think of the poor caveman.
It may appear that UI designers are just working in ivory towers, pushing arbitrary and capricious changes down upon you. When you find yourself thinking that way, just think of the poor caveman.
Exactly. Now compare to this:
"Treat people as if they were what they ought to be and you help them to become what they are capable of being." -- Johann Wolfgang von Goethe
That is the perfect antithesis to Microsoft, Apple, Google, Facebook, Twitter, the list goes on.
"Treat people as if they were what they ought to be and you help them to become what they are capable of being." -- Johann Wolfgang von Goethe
That is the perfect antithesis to Microsoft, Apple, Google, Facebook, Twitter, the list goes on.
And kids. You'd be surprised to know what kids are capable of only if you talk to them in a matured way. Throw them in the deep end intellectually and be very amazed at how much they can think.
It's dangerous. What if you had pressed Cmd + S before you did Save As (my hands have a reflex, I press Cmd + S so often it annoyed me that NetBeans will actually disable the shortcut and give me the warning bell instead because the file hasn't been changed). Now the original is gone. You really should duplicate the file and then make modifications.
Also, with the new Versions stuff in Lion/Mountain Lion you don't have any extra data leakage. The latest file on disk (depends on the app I guess, but most naive apps that use Versions) will be just that, the latest, unlike Word where retrieving old versions/text is relatively simple and can cause an hotbed of issues...
Also, with the new Versions stuff in Lion/Mountain Lion you don't have any extra data leakage. The latest file on disk (depends on the app I guess, but most naive apps that use Versions) will be just that, the latest, unlike Word where retrieving old versions/text is relatively simple and can cause an hotbed of issues...
> It's dangerous. What if you had pressed Cmd + S before you did Save As
Then I press Cmd-Z a few times and save again. It's really not so bad. And in this supposed glorious brave new world of auto-versioning, the old version is still available right? So even if I totally forgot it still wasn't "dangerous", at least any more than the new behavior is so.
Then I press Cmd-Z a few times and save again. It's really not so bad. And in this supposed glorious brave new world of auto-versioning, the old version is still available right? So even if I totally forgot it still wasn't "dangerous", at least any more than the new behavior is so.
So ... after Duplicate hit Cmd + Z a couple of times and fix the issue. You just solved the problem yourself.
As the sibling reply said, in that case I'd go with Cmd+Z. What you just described is a benefit of the versions feature and NOT that of removing "Save As". And I do not need the OS to do the versioning. "Save As" has never ever been dangerous. What you described as danger is the carelessness of saving the edits in the opened file and that has nothing to do with Save As.
Oh man, that is seriously broken. I save-as in Preview all the time when cropping or color-adjusting photos, and this could've produced a very bad day if I had upgraded to Mountain Lion and kept doing that, unwittingly overwriting all my originals. (I haven't upgraded yet, partly to let things like this be come to light before I dive in.)
It doesn't overwrite all your originals because files are versioned in Mountain Lion. If you accidentally save changes to your original that you don't want, you can just revert to a previous version.
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.
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.
In Mountain Lion, you don't need to accidentally save changes to original.. it automatically does when you hit Save As (which shows up when holding the Option key). And that is where this becomes bloody annoying. It means every time I do a Save As, I have to revert the "original" file to its "original version". That's idiotic.
I highly doubt this will be fixed in any of the future 10.8.x updates.
Is there something fundamental about the API that makes you say that, or just understandable cynicism?
Since it's a feature, not a bug http://support.apple.com/kb/HT4753 http://www.apple.com/osx/whats-new/features.html#autosave
In Lion, Apple changed the File model completely (everything is saved automatically by default. you no longer have any "in-flight" changes that aren't saved), but they haven't properly educated the users, causing people to assume it's "broken".
With the new model, if you want to edit a copy of a file instead of the original file, you need to Duplicate first. I've been bit by this a few times as well, since it's hard to break 20 years of habit, but from an outside perspective I think the new model is less technical and could be more intuitive to new users (real life has no equivalent to "unsaved changes").
With the new model, if you want to edit a copy of a file instead of the original file, you need to Duplicate first. I've been bit by this a few times as well, since it's hard to break 20 years of habit, but from an outside perspective I think the new model is less technical and could be more intuitive to new users (real life has no equivalent to "unsaved changes").
"With the new model, if you want to edit a copy of a file instead of the original file, you need to Duplicate first. "
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.
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.
Apple's answer to this is that you if you made changes you don't want to keep, you should revert them. In Lion you had to use Versions for this, but Mountain Lion can revert to the last opened version.
That's an answer to the wrong question. I want to keep the changes I'm working on, under a new name, and keep the original untouched. Or maybe I made 5 edits to the original but the 6th edit I want in a new file (happens all the time). It just seems unnecessarily complicated. Having documents automatically save is great but it should require taking away so many other features.
You think the question is wrong because you aren't in the new model. Again- everything is continuously saved. There are no "in-flight" changes.
What you want to do is keep your the changes you made today and save a copy of an old version from earlier today. The way you do that is to revert the file to the beginning of the day, duplicate this "original" version, then revert back to the version with all your changes from today.
It's more steps, but hey, you retroactively decided a past version was important enough to save a copy of.
What you want to do is keep your the changes you made today and save a copy of an old version from earlier today. The way you do that is to revert the file to the beginning of the day, duplicate this "original" version, then revert back to the version with all your changes from today.
It's more steps, but hey, you retroactively decided a past version was important enough to save a copy of.
The problem with both the new model and the old model is they combine two concepts: storing your work so it isn't lost by act of God or stupidity and permanently committing those changes to a specific named file and version.
I want my work continually saved so that I never lose anything but that doesn't necessary mean I want it committed every minute. What I really want to do is commit my current work to a new name leaving the original document unchanged. Duplicating then reverting achieves the same result but feels much more like I'm doing something to please the machine instead of the machine fitting to what is a common work style.
I want my work continually saved so that I never lose anything but that doesn't necessary mean I want it committed every minute. What I really want to do is commit my current work to a new name leaving the original document unchanged. Duplicating then reverting achieves the same result but feels much more like I'm doing something to please the machine instead of the machine fitting to what is a common work style.
Well put. Again, we're being forced to do the work for the machine. Having multiple automatic commits happening in another area that is something we can pull back in between actual manual 'commits' ('saves') would have been a much better alternative.
Once I 'save' to a different file name, from what I understand, automatic saves are still happening to the original file and filename - why? That makes no sense however you slice it.
Once I 'save' to a different file name, from what I understand, automatic saves are still happening to the original file and filename - why? That makes no sense however you slice it.
Indeed, real life has no equivalent to "unsaved changes". And it sucks.
Thats why a smart entrepeneur developed the eraser.
Thats why a smart entrepeneur developed the eraser.
And why OS X Lion/ML has Versions and Time Machine
That is not an eraser, thats making a copy of your current work every minute, try something new, and if you don't like it, stop what you're doing and retrieve the old one from the filing cabinet.
So now every program needs an infinite, crash and restart resistant, fine grained revert option.
I applaud Apple for their braveness in changing such a core functionality, but I don't want to imagine the trouble this brings when accessing data on network shares (or even the lifespan of your SSD cells).
So now every program needs an infinite, crash and restart resistant, fine grained revert option.
I applaud Apple for their braveness in changing such a core functionality, but I don't want to imagine the trouble this brings when accessing data on network shares (or even the lifespan of your SSD cells).
> So now every program needs an infinite, crash and restart resistant, fine grained revert option.
Yeah, which is why Apple added that in Lion so anything using NSDocument get it for free http://support.apple.com/kb/HT4753
Yeah, which is why Apple added that in Lion so anything using NSDocument get it for free http://support.apple.com/kb/HT4753
Interesting. So they didn't really take away "save as" snapshots, just the ability to name them and get to them through the filesystem.
So that whenever I want to do exploratory work that I probably want to either fork or toss, I have to go into time machine to do it, rather than simply not saving, or saving under a new name.
Apple is quickly losing touch with reality.
Apple is quickly losing touch with reality.
Or choose Duplicate on the old file, don't save the copy/give it a name, and do the work in there.
Since Lion, OS X also internally autosaves files that have yet to be saved. I've had 3-4 "Untitled" TextEdit files that I haven't saved hanging around for months, across reboots.
Since Lion, OS X also internally autosaves files that have yet to be saved. I've had 3-4 "Untitled" TextEdit files that I haven't saved hanging around for months, across reboots.
I don't mind some internal backup-copy (including undo/redo state) being made of what's currently on the screen so that it can recover from a crash, but actually modifying the file I loaded from when I never told it to save is just bad, bad, bad.
Known to Mac users as Command-Z for "Undo".
That is broken. Unsaved changes should be committed to a file that is likely your current file. This would allow them to properly implement save as.
They're leaving state management up to the end user which is almost always a bad idea.
They're leaving state management up to the end user which is almost always a bad idea.
>real life has no equivalent to "unsaved changes"
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.
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.
Versions has been the single "feature" preventing me from upgrading to Lion, and it makes me sad that things haven't gotten any better in Mountain Lion.
I want to be in control of what I save, when I save it and IF I want to save it.
Versions would be a nice feature if they worked as a background safeguard and not as the main way of persisting changes. Many times I open files to try stuff out, and I DO NOT want anything saved. With images, I end up doing this much more often than actually making changes I want to keep.
I think this whole feature is a sure way of losing data. Have they fixed how versions work with non-HFS+ filesystems yet? The last time I checked, no versions were saved in this case, but the system kept persisting your changes immediately: you edit a photo, make some changes, decide you don't want them and... too late, no way to revert to your original version.
Like someone else already mentioned in another comment, I'm about this close of installing Windows 7 in both my Macs. This is no way for a proper OS to behave and this whole "this is the way of the future, just keep up with the program" blind fanboyism is making me sick.
I want to be in control of what I save, when I save it and IF I want to save it.
Versions would be a nice feature if they worked as a background safeguard and not as the main way of persisting changes. Many times I open files to try stuff out, and I DO NOT want anything saved. With images, I end up doing this much more often than actually making changes I want to keep.
I think this whole feature is a sure way of losing data. Have they fixed how versions work with non-HFS+ filesystems yet? The last time I checked, no versions were saved in this case, but the system kept persisting your changes immediately: you edit a photo, make some changes, decide you don't want them and... too late, no way to revert to your original version.
Like someone else already mentioned in another comment, I'm about this close of installing Windows 7 in both my Macs. This is no way for a proper OS to behave and this whole "this is the way of the future, just keep up with the program" blind fanboyism is making me sick.
I honestly don't see why people are so upset. I think the way saving is implemented in MLion is fantastic. Instead of relying on old standards, the engineers are looking ahead of the time.
"Normal", non-tech people who aren't obsessed with technology, will find this feature amazing. Actually, let me correct myself - they won't notice this feature, and that's the key.
Save As was a hack, which worked for people who knew about it, but was a total clusterflack for normal users. Normal users rarely revert to old copies and if you really want a duplicate of a file, well, you can always have a "duplicate", which is an available feature.
Using the OSX in this way will be a more pleasant experience, going forward. I am not saying this because I love Apple's design, I am saying this because I've seen this countless times while helping my family with their computer issues.
"Normal", non-tech people who aren't obsessed with technology, will find this feature amazing. Actually, let me correct myself - they won't notice this feature, and that's the key.
Save As was a hack, which worked for people who knew about it, but was a total clusterflack for normal users. Normal users rarely revert to old copies and if you really want a duplicate of a file, well, you can always have a "duplicate", which is an available feature.
Using the OSX in this way will be a more pleasant experience, going forward. I am not saying this because I love Apple's design, I am saying this because I've seen this countless times while helping my family with their computer issues.
> "Instead of relying on old standards, the engineers are looking ahead"
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.
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.
I cannot believe how the Apple engineers implemented this feature, thinking this makes sense???
switch (menuEvent) {
case FILE_SAVE_AS:
NSString *newFileName = prompt_for_saveas_name();
[document writeToFile:originalFileName];
[document writeToFile:newFileName];
Files are always saved automatically in Lion/Mountain Lion. It's more like this
-(void)dataChanged { [document writeToFile:fileName]; }
-(void)dataChanged { [document writeToFile:fileName]; }
switch (menuEvent) {
case FILE_SAVE_AS:
NSDocument newDocument = [initWithDocument:oldDocument]
[newDocument writeToFile:newFileName];
They are even listing the return of "Save as" on the "new features" page:
http://www.apple.com/osx/whats-new/features.html
Quoting:
Crazy!
Edit: You're right, I saved a file.txt from TextEdit, then cat'ed it from a Terminal, then edited it even without trying to save or duplicate or save as; in fact the TextEdit window still shows "File1.txt - edited", but cat shows the new contents.
They shouldn't have brought back "save as" at all if this is they way they are going to handle things, much less list it as a killer feature of 10.8.
http://www.apple.com/osx/whats-new/features.html
Quoting:
Keyboard shortcut for Save As
Use Command-Shift-Option-S to save a document using a different name and location.
Crazy!
Edit: You're right, I saved a file.txt from TextEdit, then cat'ed it from a Terminal, then edited it even without trying to save or duplicate or save as; in fact the TextEdit window still shows "File1.txt - edited", but cat shows the new contents.
They shouldn't have brought back "save as" at all if this is they way they are going to handle things, much less list it as a killer feature of 10.8.
Did you not read what I wrote? OS X no longer has a concept of "Unsaved changes". It's always saving your file. You write in a new sentence, it saves it (virtually) instantly. The original file was already overwritten when you selected "Save As".
The new "Save As" just makes the old "Duplicate" more handy. I agree it's a poor choice of name, they should have kept it named "Duplicate".
The new "Save As" just makes the old "Duplicate" more handy. I agree it's a poor choice of name, they should have kept it named "Duplicate".
Yeah, after reading your post twice and confirming with cat in the terminal it sort-of makes sense.
They still shouldn't list "Save as..." as a new feature, because it sounds like they made it work like every other OS.
Also, the textedit window is extremely deceiving when it shows "file1.txt - edited" -- when in fact the file has already been committed to the filesystem!!
They still shouldn't list "Save as..." as a new feature, because it sounds like they made it work like every other OS.
Also, the textedit window is extremely deceiving when it shows "file1.txt - edited" -- when in fact the file has already been committed to the filesystem!!
Yeah I also don't get what the significance of "edited" is supposed to be, it just reinforces the image of the model not having changed.
It shows you that you changed the document since either opening it or creating a version. That is useful information.
Then save as should revert the original file to how it was when opened and create a new file with all the changes in that.
It should forget all the autosaves for the original file.
They should add a third (or fourth?) option: "Move changes since last opening to a duplicated file and revert this file"
It's long and would look ugly, so they'll never implement it. But they should.
(I'm not a pro git user, and don't use `stash`, but I think what I described is like `stash`ing changes, checking out into a new branch, `stash pop` and then `commit`ing...)
It's long and would look ugly, so they'll never implement it. But they should.
(I'm not a pro git user, and don't use `stash`, but I think what I described is like `stash`ing changes, checking out into a new branch, `stash pop` and then `commit`ing...)
As Mountain Lion effectively commits all changes to the current branch automatically, the Git equivalent would be:
git branch new-branch
git reset -hard <startpoint>
I think we're all conflating "worst case" with "common case" of Save As and Duplicate.
In the worst case, the traditional filesystem behavior could lose your data if you accidentally hit "Save" instead of "Save As". In the common case, it let you save off new versions without affecting your existing version.
The (Mountain) Lion paradigm removes the worst case; you can always revert and recover. But the behavior of the common case gives the appearance of lost data, and violates both Principle Of Least Surprise and Do What I Mean.
In the worst case, the traditional filesystem behavior could lose your data if you accidentally hit "Save" instead of "Save As". In the common case, it let you save off new versions without affecting your existing version.
The (Mountain) Lion paradigm removes the worst case; you can always revert and recover. But the behavior of the common case gives the appearance of lost data, and violates both Principle Of Least Surprise and Do What I Mean.
POLS = ?
DWIM = ?
Principle of Least Surprise (http://en.wikipedia.org/wiki/Principle_of_least_surprise)
Do What I Mean (http://en.wikipedia.org/wiki/DWIM)
Do What I Mean (http://en.wikipedia.org/wiki/DWIM)
I am trying to resist the urge to call Mountain Lion "Mountain 'O crap"
If Microsoft did this they'd be eviscerated crucified.
iOS Developer and Mac user here (as well as Windows).
The madness must stop. I have a feeling Steve will be missed more and more as the years pass.
If Microsoft did this they'd be eviscerated crucified.
iOS Developer and Mac user here (as well as Windows).
The madness must stop. I have a feeling Steve will be missed more and more as the years pass.
Microsoft worked for years to implement this sort of file system in Longhorn, called WinFS. In the end they could not get adequate performance and had to strip it out.
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)
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)
I did some googling and it seems like Windows 8 Metro apps might have similarly neutered file handling. Has anyone tried it out and can report?
My understanding is that Metro tends to sandbox an apps data in a way analogous to that of a mobile OS. I believe the intent is to prevent one Metro app from overwriting another apps data or corrupting the file system.
Based on how everything else works it would be simple enough for the "Save As" to basically "Duplicate and Save." You press it, give it a file name and you how have two windows. Don't know why Apple didn't do it this way.
That is how it works now. When he says "it silently saves the original file", he's missing the point that OS X is always saving your files.
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.
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.
In ML you can set "Ask to keep changes when closing documents" in the system preferences.
Then OS X is not supposed to overwrite your file without your consent, but it does in this case.
Then OS X is not supposed to overwrite your file without your consent, but it does in this case.
Does it? The linked blog post makes no mention of the preference setting you describe, so the author was probably running without that setting (which is off by default). I'll have to try that when I upgrade to ML next week.
Yes, I tested it.
Before displaying the Save As dialog for naming your new file a write to the original takes place. They probably just do a copy and rename file operation afterwards.
Interesting fact: if you abort the Save As dialog and try to close the original they ask you to "Revert Changes".
Before displaying the Save As dialog for naming your new file a write to the original takes place. They probably just do a copy and rename file operation afterwards.
Interesting fact: if you abort the Save As dialog and try to close the original they ask you to "Revert Changes".
Ah in that case it's definitely a bug.
It's not a bug. It overwrites the file by design.
The old model was revert-by-default. You had to manually save your changes.
The new model is save-by-default. You have to manually revert your changes.
In the "File" -> "Revert To..." menu you have multiple options, such as revert to last saved document and revert to last opened document. These persist even after restarting the application.
I think the new model is far better design.
The old model was revert-by-default. You had to manually save your changes.
The new model is save-by-default. You have to manually revert your changes.
In the "File" -> "Revert To..." menu you have multiple options, such as revert to last saved document and revert to last opened document. These persist even after restarting the application.
I think the new model is far better design.
The big question here is data loss, which the article alleges but does not really prove. The author basically says "I don't understand versions, so I don't trust them."
Many folks have pointed out that since Mountain Lion auto-saves all file versions, there actually is not any data loss. Just revert the file.
However, my reading of the Apple support document [1] is that versions are discarded over time. It says:
> OS X Lion manages the version history of a document, keeping hourly versions for a day, daily versions for a month, and weekly versions for all previous months.
This would seem to indicate that if you downloaded a file from your camera, then made changes that were autosaved to the original file, the original version would be discarded after 24 hours had passed--the several "hourly" versions reduced to a single "daily" version.
If that is true, it is really problematic. If version control software is to be trusted, I think it should not discard versions.
[1] http://support.apple.com/kb/HT4753
Many folks have pointed out that since Mountain Lion auto-saves all file versions, there actually is not any data loss. Just revert the file.
However, my reading of the Apple support document [1] is that versions are discarded over time. It says:
> OS X Lion manages the version history of a document, keeping hourly versions for a day, daily versions for a month, and weekly versions for all previous months.
This would seem to indicate that if you downloaded a file from your camera, then made changes that were autosaved to the original file, the original version would be discarded after 24 hours had passed--the several "hourly" versions reduced to a single "daily" version.
If that is true, it is really problematic. If version control software is to be trusted, I think it should not discard versions.
[1] http://support.apple.com/kb/HT4753
That's insane; it must be a bug. Perhaps they should just stick with the new document model. We'd have to relearn, but a clean break is better than this nonsense.
I dislike auto-versioning as I have no control over the process or even an understanding of the space used
In this era of cheap terabyte-scale storage, concern about the space used for versions of a document is NOT something that should occupy your mind.
In this era of cheap terabyte-scale storage, concern about the space used for versions of a document is NOT something that should occupy your mind.
Because my Mac Book Air has terabytes of free space??
The files are chunked and only the pieces that have changed are stored across versions. In all but the most corner of corner cases, the extra storage used is negligible. (This same chunking also helps iCloud keep iCloud-stored files in sync across devices without using a lot of bandwidth or being out-of-sync for as long during the upload/download process.)
Mountain Lion made me greatful for bootcamp. I've resolved to use my Mac Mini as a Win 7 machine from here on out.
Is "duplicate, then save" common sense enough?
If we were starting without multiple years of experience using "Save As". The problem is a workflow that was expressly used by people to not mess up the original now messes up the original. This is so not good. If we were using OpenVMS (versioning of files is obvious), but it is really a bad design decision. Bringing auto saves to the Mac in the way they did is foolish.
Anyone coming from an iPad or iPhone has no experience of "Save As". These are the users Apple are now targeting. Like it or not.
Anyone coming from the iPad has no experience with the File menu, and Mac users have years of experience with it. Learning a new interface requires learning some new customs.
This is a huge issue with creation in iOS. It is not a form factor or input problem. It is this strange assumption the every action I do is correct and needs to be preserved. I cannot know that my rewrites will be good before I attempt them. Reverting on iOS is a huge pain if its even possible at all.
This is a huge issue with creation in iOS. It is not a form factor or input problem. It is this strange assumption the every action I do is correct and needs to be preserved. I cannot know that my rewrites will be good before I attempt them. Reverting on iOS is a huge pain if its even possible at all.
I wonder if/when Apple will bring Versions to iOS. It seems iCloud on OS X supports it at least.
The problem is that "Save As" has a very specific meaning that Apple's new implementation doesn't respect. In every other DE / other OS X applications / prior versions of OS X, "Save as" means "take the current working copy and save to disk under the given name, presevering the original". In Mountain Lion, "Save As" basically means "Rename". If Apple called the feature "Rename", this wouldn't be an issue; it's an issue because Apple co-opted a very well-established term for a completely different function
Looks like it's not just SaaS that is susceptible to major feature disruption.
If Steve were here, he'd say "Just Save Your Files Differently."
This really messes with the way I work with images. I'll open base prototypes and start playing with changes not knowing at that point if I'll want to save them or not. If I end up keeping them, at that point I'd save as a new file. Seems like auto-save should be app level preferences that should be able to be turned off. I don't want to duplicate a file every time I want to do some experimentation!
> I don't want to duplicate a file every time I want to do some experimentation!
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.
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.
For the layman I understand this kind of functionality. But as a creative who is constantly saving multiple modified files for clients, this is awful. I'm assuming/hoping Adobe will not integrate this 'feature'.
Apple should have at least changed the semantics. The term 'Save as' is understood by the majority of users to be what it has been for the last couple of decades.
Apple should have at least changed the semantics. The term 'Save as' is understood by the majority of users to be what it has been for the last couple of decades.
It looks like others have found a work-around by leveraging the duplicate feature another other keyboard shortcuts but this it quite annoying.
http://reviews.cnet.com/8301-13727_7-57481986-263/apple-retu...
http://reviews.cnet.com/8301-13727_7-57481986-263/apple-retu...
The workflow I've always used:
Or, in unix parlance, you cp then vi. Not the other way around.
Open file > Save with new filename > Change new file > Save changes
Or, in unix parlance, you cp then vi. Not the other way around.
In vi, though, what I usually do is open a file first, and then if I want to 'save as', I do ':w newfile'. I don't have to decide before I open the file if I want to duplicate it or not, and it would be very unexpected behavior for ':w newfile' to also modify the original file.
Often I don't know that I'm going to want to save as a new version until half way through. I some times open the original intending to make minor, non-destructive, changes, then end up making bigger changes and think "hmm, I'd better save as a different file in case I need the old one later".
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.
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.
[deleted]
defaults write -g ApplePersistence -bool no
Problem solved.
Problem solved.
What exactly happens when you do this? Do we get the old (sane, pre-Lion) behavior back, or does it just disable versions leaving everything the same (which is worse)?
You get the pre-Lion behavior back.
For TextEdit you additionally have to disable autosave so you don't get error messages:
defaults write -app textedit AutosavingDelay -int 0
For TextEdit you additionally have to disable autosave so you don't get error messages:
defaults write -app textedit AutosavingDelay -int 0
Isn't this what Time Machine (or git, or svn, or cvs) is for?
"Save as" overwrites the original file as well like "Save" does? OMGWTF
good
Unfuckingbelievable - which einstein inside one infinite loop came up with this gem?
welcome to osx the only thing osx has over other platforms is the ease to create good looking gui applications. i do miss it every now and then. but not really that often.
With the original Save/Save As, the concept was easy to understand after someone took 30 sec to explain it to you. You knew exactly what was happening.
But with Apple's new changes, Apple has made autosave and versions the new paradigm (awesome), but they've done a terrible job at explaining how to do anything but that.
How do I edit something and then save that edit as a new document without affecting the original? If I copy a file, does the whole version history get copied too? What if I send it to someone? What if I want to delete the version history period? What if I want to "duplicate" a file but not save it anywhere, because I just want to mess around with changes for a while?
I've been using Lion since it came out, and I don't really know the correct answers to any of those questions.