On Fri, 29 Jan 1999, Bart Lateur wrote: > Mac users simply seem to accept it as "the facts of life". Perhaps we > shouldn't. If the crashes mentioned on the list are any example, we most certainly shouldn't. Crashes every day in MS Office? I don't have the latest version, but I wouldn't accept it. I would track down the problem, call tech support, move heaven and earth, but I certainly would not accept it. Crashes every day in Photoshop? What on earth are ya'll doing? Crashing in anything other than development software is unacceptable. If you use that software often, and it crashes often, you owe it to yourself to track the problem down. I wouldn't stop until I figured out a workaround (removing or replacing minor third party software), got the software vendor to acknowledge the bug and promise a fix in the next rev, or both. An exception used to be Netscape, which I used to be able to depend on a revision in a couple of months which would likely solve the problem. (But I still sent bug reports.) Even if the prescription is "don't do that," you should at least find out what it is that you shouldn't do. If we buy and use buggy software without complaining to the vendor, what will change? Or if we download buggy software, and don't send back bug reports or bug fixes, whose fault is it that the problem continues? Even with protected memory, you will still get seg faults and have to restart the app. That is still unacceptable in my book. Complain! Squeak, O wheel! > On Thu, 28 Jan 1999 21:19:29 -0800, Jeff at MacTech wrote: > > >Christian Bechbuehler wrote: > >>Even when in the Finder I made a copy of the saved document. I > >>suppose the Finder knew about the existence of the file(s) but didn't > >>write it to disk, and then crashes along with everything when one (!) > >>application makes a mistake. The entry in "Recent Documents", which > >>is only an alias and now useless, is the only trace left of my file. > > > >That really shouldn't happen--most applications (the Finder included, I > >would imagine) flush the disk cache after writing a file. > > Oh it happens. Even if you have a COPY of a file on disk. It looks like > the Finder keeps a backup copy of the old version of your file. And then > the Mac breaks down. You open the file again, and bingo! All changes you > made and *saved*, have all disappeared. You have a very old copy again. > The Finder gladly overwrites your newer version with the backup, all > without one mention. I think I misunderstand you. What I _think_ you are saying is very improbable. You have a document A1. You update it, A2. You make a finder copy, B2. Then your machine crashes, and when you return you find only A1 and a B1? Are you absolutely certain this is happening, or might you be confusing the order of events? Can you repeat this event? I have very little doubt that the Finder flushes the A1->A2 update to disk before making a copy to B2, and certainly B2 on my hardware gets written right away (I hear it). At any rate, it sounds like you have funky hardware--a disk formatted with a buggy caching driver, or a RAID array, or are running in a RAM disk or other disk-caching software, or you turn the power off when your machine crashes. The only times I've been able to reliably lose data is by yanking the power cord from a running Mac. Even with a generous disk cache set, external drives with cache, and so on, I don't see anything like this. > To get this slightly on topic again ( ;-): this has happened to me with > MacPerl scripts and droplets too. Even if a newer version of the droplet > has already worked, which it cannot do unless it has actually been > saved! Sounds like hardware funkarolla to me. This certainly isn't "typical" under MacOS--and funky hardware would likely act the same under Unix, unless you removed a buggy layer of write-caching software. -- MattLangford ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch