How this passed through Apple’s Mountain Lion testing is beyond me. “If one edits a document, then chooses Save As, then BOTH the edited original document and the copy are saved, thus not only saving a new copy, but silently saving the original with the same changes, thus overwriting the original.” Just goes to show: do not mess with my ability to save my stuff. There is no one-size-fits-all for this kind of delicate stuff.
I was always under the impression that Save As is just an alias for the Duplicate command introduced in Lion, but I guess that’s not the case. In any case, Duplicate does inherit the Cmd+Shift+S shortcut from Save As. Honestly, I think the best course of action for Apple is for them to rename the new Save As command to something else, so that people are not confused.
Edited 2012-08-06 13:34 UTC
It’s not a bug, it’s a feature!
actually it is. and there is no data loss either. complete non story. the real story: how people have problems understanding the concept of automatic versioning and let go their behavior of saving everything in multiple copies.
from my own experience, overwriting the old version with the new one because you thought you already did a “save as” or did “save as” but actually where just did “save” is by far the most common way to lose your data. apple fixed that for you. to complain about that and even write something about “data loss” is just stupid.
It’s just a bug and will be fixed…
Being a bit conservative having accumulated lots of set habits over decades on computers I never took to the Duplicate function, although I understand why it might be a clearer way to do things to new users, so I used the technique shown here
http://www.tuaw.com/2012/07/29/get-save-as-back-on-mountain-lions-f…
to permanently replace the Duplicate menu item with a ‘Save As…’
So this bug is a bummer, let’s hope they get if fixed in 10.8.1
Save as is not deleting your info. Auto save is saving you changes over the original.
If you make changes to the original document auto save will save your changes.
Then when you click “save as” you get a new copy of the document with you changes.
Well spotted.
This shows you how to disable Auto-Save on a per app basis, does anybody know if this works in Mountain Lion
http://osxdaily.com/2012/07/11/disable-auto-save-and-versions-in-ma…
That is still horrible behaviour. Auto-save should not over-write the original document, it should be saving changes to a hidden file which can be recovered in the case of a crash. Over-writing a document without the user saying so is a terrible idea.
I have a Numbers spreadsheet, added some stuff, saved it, did a sort on all data (few hundred lines), quit, opened it the next time only to discover all my data messed up. Lucky I had a recent backup.
(this was pre-Mountain Lion)
Didn’t it warn you that you were about to destroy unsaved changes? Seems like the logical thing to ask in that case…
The problem was that it was the other way around: it saved changes I didn’t want to save.
I changed the spreadsheet by sorting columns, just to figure something out. This is something you can undo, but not once you’ve closed the file/program.
I like a lot of the things Apple has done, but Auto Save definitely isn’t one of them. Agreed – totally stupid concept. It’s about as half baked as an auto-save or versioning concept could be.
Versions without the ability to name/describe them? Auto-save that slaps changes in and opens in that state on the next open of a document but at the same time loses the Undo command history that would at least sort of make it feel like a persistent app state? (Not that I want the auto-save bit to begin with, but if it’s there shouldn’t it at least make things feel like persistent editing state instead of keeping your changes and losing the logical way to undo parts of it?)
Open a doc, resize and go to Save As…, oops looks like the original is already modified. Oh, and really bad interface for browsing the (unnamed) versions – if you can even find the way to invoke the comparisons. Seriously just horrible.
I think you may be missing how Auto-Save actually works in OSX. Nothing is over written. All previous versions are stored and can be accessed via a Time Machine like interface by clicking the ‘Revert to’ menu item where you can browse all older versions.
The ‘Auto Save’ function actually makes it much safer because everything is saved as you work and there are multiple versions of your document that you can access at any time. Its kinda of neat and once you get used to it you just forget about it until you have a problem and want to revert a document back to an earlier version (or for example create two versions with one based on an older draft) and then its very easy.
Built in backup.
So to talk about ‘Data Loss’ as the article heading does is a misnomer, no data is lost, it’s just stored. The worse that can happen is that you have to do a couple of clicks to get it back. Hardly a big deal, Apple just have to clean up a couple of ways this implemented, which they may not do because it’s for old fashioned people like us who still think in terms of using ‘Save As’ as a back up method.
I repeat no data is being lost.
*le sigh*… all files are now versioned in OS X. If you autosave a bunch of changes, the versions of the previous document is saved. “Save as” is saving the current document under a different name. I’ve never used “Save as” under any OS to duplicate the functionality that we seem to be having issues with here? Why? Because I religiously hit save (ctrl+s or whatever) every couple of minutes. The current document on disk is the document I’m duplicating. Your usage may vary, obviously.
The issue here is the workflow. It’s that people are lazy and rely on apps not crashing and losing your work. Having lived through Acorn, Amiga, Classic Mac OS and Windows 3.1, I don’t think anyone should make that assumption. Nothing like watching the OS get a GPF and your work sailing in to the ether.
+1
The point of Lion’s auto-save feature is to abstract the intricacies of the memory hierarchy away from the user. You cannot edit a vulnerable in-RAM copy of a file for hours anymore, instead you edit a periodically updated on-disk copy that loses only a few minutes worth of work in the event of a hardware failure. That’s actually a very good thing, as it voids the need for most people’s hysteric manual saving disorder, replacing it with a superior versioning mechanism !
Really, I’d change a few details myself, but it seems to me that Apple got the big picture right for this feature.
hmm, voids the need for, “hysteric manual saving disorder, replacing it with an inferior hysteric manual copy disorder” from what I can gleam, though saving rather than copying, before editing, I’d have thought more prone to tears-at-bedtime than power failure.
Bit puzzled about what’s actually going on here…though losing an original document to save the possible loss of an edited version is counter-intuitive to how people actually think/work editing stuff. Can imagine a ‘collaborative’ document could end-up having little or no relation(unintended)to the original.
Edited 2012-08-06 16:39 UTC
See my earlier comment. I tested this behaviour and no data is being lost. What happens when you do a ‘save as’ is that the original version reflects the latest version and the older version appears as the most recent backed version. I really cannot see how anyone can lose any data doing any of this. Apple’s logic is that it’s better to have an automatic system that means everyone’s data is protected than create a manual system that is nice and flexible and familiar for a few but which leaves the majority open to data loss.
Seems sound reasoning to me. Maybe Apple will tweak it’s implementation to suit the few but I wouldn’t bet on it.
Can’t see how data isn’t been lost cumulatively. Don’t use mac but from what I understand you to mean a file is in a liner process of change and unless you remembered to copy the file from the beginning you have 2 versions, the present and the previous ‘save-as’ as the bak which is whatever variable of ‘save-as’s’ from the original.
Actually what Auto Save does is take regular snapshots of a document as you make changes and saves multiple backups going back in time which can be easily browsed and from which any number of earlier version can be retrieved.
It’s a bit eerie at first, once you first save a document in an app like TextEdit that implements Auto Save there is no longer a save item in the menu, you just open the document or close it with no dialogue asking if you want to save it. But hidden in the background and instantly accessible there is the previous version as it was before you opened it and made the changes, plus all previous versions.
Personally I think it’s great feature but it’s in it’s infancy, I am sure eventually all apps will work like this. The problem now is how would such a system cope with say a large photoshop file, or a video being edited, but that all comes down to system resources, storage, speed etc, and we all know that eventually system resources limitations get overcome.
What I want to know is where are these previous versions stored? In the document? The file metadata? Some special folder? Obviously they cannot be stored in the file proper, as if they were, most other operating systems probably wouldn’t recognize the file and would fail to open it. It concerns me because I have one small system drive and several large data drives. If the version information is stored in the file’s metadata (those annoy extra files you sometimes get when mixing OS X with other operating systems) then that’s all well and good, but if it’s using a special folder on my system drive, I’ll eventually accidentally end up with my system drive filled and that will cause other problems. I know that applications’ save states are saved in ~/Library/Saved Application State/, and that makes me wonder where versions are stored.
From some quick googling, it seems to be storing them in /.DocumentRevisions-V100/ .
This reminds me of something VMS (and several others) does: Say you create a new file called “myfile.txt”. Editing and saving that creates “myfile.txt;1”, and saving again creates “myfile.txt;2”. Opening “myfile.txt” grabs the one with the highest number – and increments that again when saving. File managers and the shells and such know about this system, and only show the newest version.
It’s not as automatic (you have to manually save), and it does require extra space (I think each version is a complete copy – at least there’s a purge command that removes all but the newest versions) – but the basic idea was and still is nice.
I’ve not used VMS for years (since 1996/97), but as I remember it your first document was “mytext.txt;1” right off the bat. You could also use the “purge” command to delete all of the revisions, or “purge myfile.txt” to remove all the revisions leaving just the latest (very handy when you have a low disk quota.) It was pretty cool. Pity the VMS shell was so weird and un-Unix/DOS like. I’d love to see some of the features it had in a current OS.
Right – I’ve only barely played with OpenVMS myself (I got my hands on an Alpha PWS 433u long after it was current, and managed to get hold of a hobbyist license of OpenVMS for it). I did mention the purge command, though.
And indeed, the shell was weird. More so for someone like me that is used to unix, I guess.
I found a detailed explanation here:
http://tekonomist.wordpress.com/2011/08/06/mac-os-x-lion-file-versi…
Quite cool how it was implemented, and at least it’s smart enough to store the document revisions on the drive and partition that actually contains the document. I do agree though that at the moment, requiring two workflows can be jarring depending on the application you use. Still, if Apple had made it mandatory, I can only imagine the bitching that would result. With this, plus the ability to get the Save As command back even in programs that do support version control, I think everybody can be happy though at the cost of a little complexity. I rather hope that the majority of programs move over to this method in time. I won’t deny that at first I absolutely hated it, however after reading up on how it actually worked and playing with it, I actually prefer using versions when possible. The drawback is, of course, that it depends on Mac-specific metadata which means you really can’t share versions with non-Mac users even if you give it to them on a fat32 or NTFS formatted drive. No other os knows about Apple’s versioning scheme and indeed, Windows has its own versioning mechanism for certain file types. Also, if you clean the Mac data from a drive you intend to share (something I always do before sharing it) your versions are erased from that drive. Therefore, always keep your source material on drives you don’t intend to share.
It occurs to me that we really could benefit from an open standard along these lines. Of course, even if we had one, no one would implement it except *NIX. Still, a guy can dream.
You don’t really need two workflows. You can use 1. If you always duplicate the document before you edit it, you are covered. If you don’t want to duplicate it, then don’t. Just assume that you are constantly saving the document in that background. That’s all. This is how I’ve always worked and it scares me when people don’t save regularly.
As far as I can tell, there is no need for manual copies. Since OSX also includes automatic file versioning, a backup of the old document is also silently made when you start editing it, and one can easily go back in time and restore the old version as needed.
This file management paradigm works a bit like how WordPress manages its blog posts : when you edit a blog post, you can create a new snapshot at any time using “Save Draft” or Ctl+S, and then restore them using a bunch of links under the editor. The online copy of the current snapshot, on its side, is silently backed up every few minutes. My experience with it is that so far, I did lose some data once or twice due to over-enthusiastic blog post editing, but that is nothing compared to the entire blog posts which I used to lose on my former CMSs when I pressed the “Submit” button without reminding to manually save the post to a text editor before, and then faced an Internet connexion or CMS failure. With the way OS X also automatically makes restore-able snapshots from time to time, I even could have reverted most of the unwanted changes easily. So as far as I’m concerned, this works perfectly.
I agree that this is at odds with current file management practices, though, and that Apple should not have pushed it to legacy users who are used to the old ways of file management without some kind of explanation and opt-in mechanism for them. What’s more, as someone else mentioned, an issue with Auto-Save on a legacy OS like OS X is that not all software will implement it, resulting in an inconsistent UX. But it seems to me that this is also a sensible path to head towards in the long run.
Edited 2012-08-07 05:35 UTC
Let me fix the workflow:
Old workflow:
1) Open document
2) Edit document (without saving)
3) Save document as new name
New work flow:
1) Open document
2) Save document as new name
3) Edit document
Old workflow gives you no security for document safety and the backup is only as good as whatever editor has built in (usually by a third party.)
The new workflow gives you the same result, except you also benefit form OS level auto-save and file versioning.
I know which one I’d prefer.
The last time I lost a document was when Word 2010 was installed on a new machine, the install didn’t have auto save turned on and Windows decided to auto restart the machine to install updates. This was a new document I’d worked on for an hour on a train. I broke my own rules – I only saved the initial paragraph then forgot to hit save (assuming auto save was doing that for me) and I lost 40 minutes work. It’s a mistake I don’t often repeat. One just needs to retrain oneself. That’s all.
To me the best feature is that it’s opt-in on the part of apps and that at least Photoshop and some other apps I use a lot don’t opt-in. [Yet?] I really find it to be one of the most annoying things I’ve ever dealt with for content creation – having to now manually remember to revert all changes out of a file before closing the app or window if I actually want to discard them, or having to make duplicates ahead of time just to do temporary operations – otherwise having what are in many cases just tests or throwaway changes on graphics and 3d models overwriting the originals.
Most apps are stable enough to not worry about them suddenly quitting, and most already had a timed autosave that you could use to open the file with the changes that were in progress while leaving the original file alone. Much nicer for how I work.
Oh, and as a bonus – DON’T think that autosave will protect you if the app crashes, at least not any more than having timed backup/temp files written out. If the app hasn’t autosaved your most recent changes yet, they’re lost in case of a crash! Surprise!
It works well in Apple programs. Unfortunately the crashiest and/or most critical programs mostly Office and Matlab ( Netbeans, Eclipse you get used to source control ) don’t implement this feature.
This means that one cannot let go of the instinct to save meaning one has to keep two different paradigms in ones head at all times…
Edited 2012-08-06 18:20 UTC
Apple hardware ? Fail ? impossible ?
Heh, I live in a weird country where Apple laptops can have the same problems as others, including clogged up fans and overheating, random resets, failing motherboard power lines, keyboards, and wireless chips…
Most likely, we are holding them wrong.
To be fair, I got a Macbook the same time as I got my last Dell work laptop. Guess which one is still working and has enough charge in the battery to last over 2 hours? Not the Dell. The Dell travelled a little, but mostly got left on a desk. I think Nvidia was the real culprit, but it’s pretty much a relic of the “parts” cupboard now, along with a similar model that was about 6 months older.
Again, I’ve seen Apple’s gear get a lot of praise like yours around the web, it just so happens that the one owned by relatives hasn’t been so bullet-proof. So I have to wonder if they were just unlucky, or if it is the guys who praise everything Apple for being indestructible that were lucky.
Since Squaretrade’s reports put Apple’s laptops on par with others as far as reliability is concerned, I tend to lean towards the later option. After all, if there was a magical way to make consumer electronics more durable, every PC OEM would know about it by now.
I no longer give Squaretrade the time of day, ever since I tried one of their extended warranties on a device I purchased and they absolutely refused to honor it. Waste of money. That being said, laptops fail, no matter who makes them. All hardware can fail in time. I’ve had Apple machines die, along with HP and Asus. Having said that, perhaps I’m just lucky, but my Apple machines have generally lasted longer before dying. I don’t think it’s some magic trick that Apple does as some people who are heavily in the rdf seem to believe, but their build quality has generally held up better for me (though they’re certainly not Toughbooks).
Yep, but these are the OEMs that are so stuck in a race to the bottom that, even if they did know about a way to magically up the durability of their hardware, they’d never do it and would just keep filling their machines with more and more crapware that nobody wants. A bit of an exageration maybe, but I’m damned if I can actually find a half-decent PC OEM these days which is why, when I want a Windows or Linux machine, I build my own.
If you know of a reliable way to hand-build a laptop, I would be highly interested. I too avoid OEMs for desktops, but for laptops I’ve never felt like I had a choice.
If I drop tested both of them, they’d both be former laptops, so that’s not the point. As I said.. both travelled. The Dell was probably used more and for longer periods, but it was the poor quality of the build that killed it. It will randomly freeze and give corrupt video (as I said, Nvidia chipset, probably one of the bad Nvidia graphics processors.) Macbook is still okay, still boots in to Windows 7, Lion and Snow Leopard fine. Still works for extended periods on battery (and battery life is diminished because of age and the fact I maxed the RAM and put a 7800rpm drive in it.) And is still prefectly fine in all respects as a daily driver. I’m not claiming magic – this is all anecdotal anyway, just that average use of two similarly aged laptops the (fairly) generic PC lasted less time than the Macbook.
There we can agree
On a side note, it is unbelievable how long old computers like the first-gen iMac or the PC 1512 could last without any hardware fix other than replacing batteries. My guess is that at the time, they were so expensive that failures such as that of the Geforce 7600M and 8600M was unacceptable.
It is a D830, but it was build to order with XP on it and I don’t think Nvidia was part of the standard model. Looks like a “256MB NVIDIA Quadro NVS 140M”… it just freezes. Pulling off the keyboard and running with the motherboard exposed, it’ll run for hours. Put it back together, lasts between 10 minutes and half a day. Fans look good. Heat sync looks okay. Might be bad RAM, might be a failing Hard drive, might be the graphics card (my thought), but it’s more work that it’s worth trouble shooting the issues. There was a D820 that did an identical thing last year and that was confirmed to be the Nvidia graphics card, so I’m pretty sure it’s just dead.
Many people use Save As to construct a template that will be used as a baseline for several other documents. It’s such a common practice where I work that nobody thinks twice about doing this.
That practice goes right out the window with this bug. So, how are we to create shared templates that won’t get overwritten the first time someone tries to create a new document from a template?
By “Locking” the file. I think this was a feature since Lion. It would auto-lock the file after not being edited for a while, and it would offer you to duplicate the file. I think you can lock / unlock the file at will, but I haven’t tried.
But I agree, this is breaking existing workflows. May be good, may be bad.
My guess would be to save-as with new name BEFORE you edit anything. This is how I have always done it, just to be paranoid.
The template file could always be set to read-only for the extra paranoid.
I believe this seems to be a case of lack of proper QA in the post Jobs era. It started with the dry marketing. This situation was inevitable.
It’s been that way for a long time now, at least since OSX 10.5 or so.
As other comments said, this is both a feature and an annoying thing : it’s awesome because it combines the auto-save feature with the duplicate file feature, but it’s annoying because it destroys the original file.
Since 10.5 (could be earlier), I always open the original document, immediately do a “Save as…” and edit that newly saved document. My original document stays untouched.
Besides, it’s exactly the same on MS Windows: “Save as…” also overwrites the original. So: non-story.
+1 Exactly.
Except, as documented here. the original file is still versioned, so nothing is lost on Mountain Lion.