My biggest problem is that Apple is not explaining these changes.
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.
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.
> 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.
An entirely new history? Doesn't that kind of
suck? It would be preferable to have the copy also
retain history prior to duplication.
> 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.
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).
> 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'll agree with this. Maybe the middle ground is
something similar to OS X's metadata dot-files
(i.e. ._.filename).
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.
Then the application and the file format should probably have a way of storing older texts by itself, much like Microsoft Word. Although you do lose the data leakage protection. If I make a Duplicate of an image or file I generally want that as my starting point and not have the entire version history copied as well.
> 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).
No, please for the love of all that is holy please do not drop more ._.crap in my directory trees. Some of us still live and breath command line or connect to various non-Mac OS X machines and seeing those files everywhere is extremely annoying.
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?
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.
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"...
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).
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.
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.
"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.
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.
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.
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 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.
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.
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.
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.
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! ;)
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 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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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...
> 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.
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.
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.
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. "
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.
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.
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.
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 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.
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.
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.
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 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.
> "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.
Keyboard shortcut for Save As
Use Command-Shift-Option-S to save a document using a different name and location.
It does not say "Use Command-Shift-Option-S to save a document using a different name and location and also overwrite the existing document", even though that's exactly what it does!!!
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".
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!!
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...)
which is effectively what people are having to do in Mountain Lion by hand. The difference is that Git users expect that and know how to do it, unlike your average new Mountain Lion user coming from OS X 10.6 or Windows.
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.
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)
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.
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.
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".
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.
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.
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.
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.)
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 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.
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
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.
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.
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.
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)?
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.