[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] looking at Mac OS X



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