Re: Re: Corrupted NB
- To: mathgroup at smc.vnet.net
- Subject: [mg14508] Re: [mg14419] Re: Corrupted NB
- From: gwinn at ma.ultranet.com (Joe Gwinn)
- Date: Thu, 29 Oct 1998 04:33:09 -0500
- Sender: owner-wri-mathgroup at wolfram.com
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 -- put a simple checksum on it. By the way, there is a simple trick I sometimes use oon apps that eat their prefs file -- manually make a backup copy, and/or manually write-lock the 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. Joe At 1:39 AM 98/10/23, Garrett Tim Sos 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