Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!news-out.readnews.com!transit3.readnews.com!panix!not-for-mail From: Bread Newsgroups: comp.sys.mac.system Subject: Re: Losing my religion(?) Date: Wed, 15 Aug 2012 10:45:17 -0700 Organization: lined up neatly Lines: 114 Message-ID: References: <120820121955223103%star@sky.net> <5028a772$0$1490$c3e8da3$1cbc7475@news.astraweb.com> <50295eb0$0$1694$c3e8da3$dbd57e7@news.astraweb.com> <130820122332101451%star@sky.net> <502b2928$0$44471$c3e8da3$f017e9df@news.astraweb.com> NNTP-Posting-Host: localhost Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: reader1.panix.com 1345052719 4067 127.0.0.1 (15 Aug 2012 17:45:19 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 15 Aug 2012 17:45:19 +0000 (UTC) User-Agent: Unison/2.1.9 Xref: csiph.com comp.sys.mac.system:29507 On 2012-08-15 05:04:00 +0000, Rich Gray said: > JF Mezei wrote: >> Lewis wrote: >> >>> No it doesn't corrupt anything at all. This is a complete and utter >>> misstatement of facts. The original unedited file is not lost, >>> discarded, overwritten, nor destroyed. >> >> Based on my understanding, at the unix level, the actual file is fully >> overwritten when the document is saved. a "cat" of the file will show >> the new modified contents and the old contets are not available. > > I did this experiment under Lion: In a terminal window, I cd'd to the > desktop and created a .txt file using vi. I exited vi and opened the > file in TextEdit. I then simulated the proverbial cat walking across > the keyboard and quit TextEdit. It closed without warning. I > re-opened the file in vi and the 'cat tracks' were there. That's precisely what happens. > >> So autosave will "corrupt" the file. > > Indeed. Correct. Which is, as I've been saying, why file locking is so important. From the very beginning, I've been saying that autosave and versions is still an unfinished idea. Apple tried to make it "interfaceless" and make it "just happen" but version control and such automation is simply not that easy. In more serious revision control systems, there are several variations of how to handle locking of files, generally important when more than one person may be modifying the same file, but similarly important in keeping unintended changes from getting checked in. In one model, before you may modify a file, you needed to check it out and lock it - preventing anyone else from editing the file - before you could edit it. In another model, your copy was always able to be edited to your heart's content immediately. In both cases, your changes would not be checked into the system at all until you explicitly checked them in. Apple wanted to do away with the "you need to check in your changes" part - because folks who aren't trained in revision control systems wouldn't remember to do their check-ins. But Apple also went with the lazy system of "you can edit immediately without having to check out and lock your copy". And *I* think that was the mistake. Until you declare "I *am* going to edit this file" the file should not be editable. The old system, before versions, was "you can edit this file immediately without having to check it out, but if you forget to save your changes, you may be screwed, and by the way, if you edit the file, since you've been training yourself to save all the time, you may overwrite the file when you didn't mean to, and you won't be able to recover the old version unless you are using Time Machine". Unfortunately, they've muddled it. As we've demonstrated, (a) unintended changes can get saved to a file - dangerously - because they get saved even if you never hit "save"; and (b) it's not enough to say "okay, then you can go to Versions and get back to what you intended" because (i) you shouldn't have to do that; and (ii) because - and here's the other dangerous part - the versions database is hidden and gets lost without warning if you move the file to another filesystem or are using a sync system like Dropbox. Unless the version history is tightly tied to the file, so that it cannot get easily lost, it's *not* enough to say "just go to versions and revert". And even if it were enough, that's not a very reasonable solution. You shouldn't have to go out of your way to recover from problems that shouldn't happen anyway. Accidents (ie. cat walking on keyboard) happen. It's important to make recovery from those accidents easy (hance, in theory, being able to roll back a version), but it's even more important to minimize the likelihood of those accidents happening in the first place (by making it harder to accidently screw up your file in the first place). It's the difference between having airbags and avoiding the obstacle in the first place. Obviously you should have airbags. But even better is not crashing the car in the first place, so before you worry about airbages, you make steering secure and predictable. > >> Just because some GUI application allows you to reconstitute previous >> version of the file from a "versions" database does not detract that the >> file itself is fully overwrtten whenever you save or auto-save it. > > Well, I expect it to be overwritten on a Save. ;) Auto-save is dangerous. I agree. As it was in Lion, in my opinion, it was still "beta" - not a fully fleshed out product, and still with signficant flaws. It should be optional, like the "natural" scrolling and the hidden scrollbars. I do not understand why it wasn't optional. But I do think, overall, it's a *great* thing and once they get some of the things we're talking about here worked out, it'll be a vast improvement for most people. It's certainly *not* the catastrophe that people have been painting it. > >> The problem with auto-save is that >> one doesn't know ifhen it decides to mofidy a file or can't prevent it >> from modifying a file you have no intention of modifying. > > Right. The program which can change a file is usually the viewer too. > "Just looking" is now dangerous. Unless the file is locked. Which happens automatically after two weeks. It *should* happen a lot sooner than that. The more I work with it, the more I'm convinced of this.