I have been bitten by this too.
There is a simple way Wolfram could at least make Mathematica aware that
a prefs file had become corrupted (by other than Mathematica?) -- put a
simple checksum on it. This would allow Mathematica to know that the
file was damaged, and tell the user, rather than to become weird.
By the way, there is a simple trick I sometimes use on apps that too
often eat their own prefs files -- manually make a backup copy, and/or
manually write-lock the active prefs file, so the app cannot write to
its own prefs file. Most apps will tolerate this, although I haven't
tried it with Mathematica. It is a bit of a nuisance, as one must
unlock the prefs file to change the prefs, but has been effective in
the past.
A variant of this would be to require Mathematica to get specific user
permission to write to the prefs file: a last-chance "commit" button.
This, combined with a checksum, should greatly reduce the level of
trouble from pref file damage, even as the bulk of Mathematica evolves
and changes.
Joe Gwinn
In article <70rkmi$4u5$9 at dragonfly.wolfram.com>, Garrett Tim Sos
<gts at mindspring.com> wrote:
> Maybe this idea should also apply to the preferences files that still
> (version 3.0.1.1x) become corrupted (on the Mac, atleast) so often that
> I no longer try to change from the factory default preferences.
>
> I logged a call to WRI on a different issue and asked about the
> preferences file corruption problem and got the answer that it was "the
> computer's fault" implying that they did not feel it needed to be
> fixed.
>
> Maybe he was just having a bad day but sometimes it is hard to like
> WRI. I have been using Mathemetica since Version 1.1. It is a
> wonderfully complex creation but 3.0's habit of destroying user INPUT
> (preferances, notebooks and strange corruption of cells) is dreadful.
>
> Tim
>
>
> Joe Gwinn wrote:
> >
> > I have also had this problem, but I have never succeeded in fixing a
> > damaged notebook. The problem has always happened when Mathematica
> > crashed while saving the notebook Now I periodically make a no-output
> > backup copy called "<whatever>.nb short" so I don't lose everything
> > when Mathematica crashes.
> >
> > This kind of destroy-file-on-save behaviour was very common in early
> > (mainframe and mini) computer software, and subsequently in early PC
> > and Mac software, but is now mostly a thing of the bad old days. The
> > standard solution is to do file saves in such a way that there is never
> > a window of vulnerability, where a computer crash (for whatever reason)
> > could leave one with only a corrupted file.
> >
> > The method? Simple. One 1970s variant: Open a temporary file and
> > write the new version of the document into it. If successful, rename
> > the old file with a temporary name, and then rename the just-written
> > temporary file (containing the new document) to be the updated file.
> > Delete the old file with the temporary name. No matter when the crash,
> > there is at least one good file surviving, perhaps with a temporary
> > name. Temporary files are not deleted on a crash, so this can work.
> >
> > This does require that one have scratch disk space sufficient to carry
> > an extra copy of the file, but this is generally true, especially in
> > this day of multi-gigabyte disks. More to the point, this method was
> > used even when disks were tiny, so one can conclude that users would
> > rather have bulletproof file saves than the extra disk space.
> >
> > Joe Gwinn
> >
> > In article <70dd69$234 at smc.vnet.net>, "Kevin J. McCann"
> > <kevinmccann at Home.com> wrote:
> >
> > > I have a NB which when I try to run it tells me that there was a syntax
> > > error. The popup goes on to say that I can open it as a text file,
> > > etc. Is there a way to recover from this. The problem appears to have
> > > been generated when Mathematica crashed.
> > >
> > > Kevin