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:52:02 -0700 Organization: lined up neatly Lines: 55 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> 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 1345053123 5420 127.0.0.1 (15 Aug 2012 17:52:03 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 15 Aug 2012 17:52:03 +0000 (UTC) User-Agent: Unison/2.1.9 Xref: csiph.com comp.sys.mac.system:29508 On 2012-08-15 04:46:00 +0000, Rich Gray said: > Lewis wrote: >> In message >> Rich Gray wrote: >>> TextEdit is a perfect example. It's a Swiss Army knife, which I make quite >>> a bit of use of, but more often than not, as a *viewer*. One of my most >>> common sins is typing into the wrong window when working in many windows. >>> With Auto Save, this immediately corrupts the original file. >> >> 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. > > The file is no longer correct. Corrupted is a reasonable expression > for invalidated content. The original, unedited file is not there anymore. It may be recovered, possibly, via Versions, but if you go look at your filesystem, it's not there. There's a new and incorrect file. "corrupted" is a reasonable word for it. > If you don't like it, pick another. The file is now wrong and will be > until the error is noticed (perhaps spectacularly) and corrected. The > fact that the file is recoverable does not change the fact that it has > been made wrong. The real danger is that the file may *not* be recoverable. The versions database is stored in an invisible database at the root of that filesystem. If you move the file to another drive, the version history is lost and the file before the unintended edits is *not* recoverable. >> This would be a good reason to have keep the file locking in 10.8. > > It does seem like explicit locking & unlocking (without having to jump > through Finder hoops) would be good. But that would probably be too > much for the simpleton environment Apple is trying to create. :/ The > two week auto-lock is strange... (I can screw up a lot of stuff in > that time!! ;) *immediate* auto-locking whenever the file is closed would be a better solution. If you open a file, you need to explicitly say "okay - I *do* mean to edit this!" before you are allowed to edit it. Every time. The assumption shouldn't necessarily be "just because I've opened this file, I intend to edit it and save my changes". Two weeks was just some oddball compromise between some folks over at Apple. Autosave and Versions are a *good* thing. They're just not quite finished. Locking needs to be improved, and transparency as to what's happening needs to be improved, as does the issue of keeping the revision database attached to the file, if possible. It's too easy to lose your revision history right now, and it happens without warning or hope of recovery.