Well, I haven't studied the recovery capabilities of either journaling file systems or the alleged recovery capabilities of Word, so I can't discuss the differences.
I can tell you that the FinalWord "state-save" feature was a database with 1K pages that updated the db not every X minutes, but every time the user paused X (milli)seconds between keystrokes, so the backup was very fine-grained. And I know that this database, kept in a swap file, was readable by the word processor. On rare occasion I have had to read the old swap file into a new, empty swap file in order to retrieve text that I had doubly deleted and wanted, on second thought, to have back. Do this with your journaling file system. To save a backup every X minutes is not at all the same thing, partly because it commits automatically all the changes you've made, (this first began to appear in DOS-based word processors in 1983 after I suggested it to Jim Edlin, the developer of another word processing program -- and after all, it's a pretty obvious need once you think about it). But my original point was merely that other databases, and other types of data entry programs (such as spreadsheets) need to have user-friendly disaster planning and recovery. Those that do not, are designed for some cyber-utopia, not the real world. I know that whatever the journaling file system does on my Linux systems, it does invisibly to me, and I am unable to consciously use or manage it; I simply know that my linux systems come back much, much faster after a hardware crash than before ext3. And that this makes my dying machine usable (for the three hours it will stay alive). But it does not make the OpenOffice or Applix doc or the image in the gimp that I was working on at the time of the crash magically (or manually) reappear. But that would be desirable. And it's no longer possible to argue that the processor speeds are too slow or the hard drive space too dear to make this uneconomic. Saving the state of the application every XX milliseconds is simply a good idea. Unless you have perfectly reliable power, OSs and apps. Best wishes, dan johnson, user On Fri, 2004-07-30 at 17:50, K.S. Bhaskar wrote: > Dan -- > > If you run something like Open Office (which has a "Save every x > minutes" feature) on Linux using a journaling (e.g,, ext3 or Reiser) > file system, what do you lack in disaster recovery compared to FinalWord > on DOS? In fact, for added security, you can tell it to make a back up > copy of a file when you edit it. > > Similarly, if you were to run VistA on GT.M (with journaling turned on) > on Linux with an ext3 or Reiser file system, you have protection against > data loss in the event of a power outage. > > Regards > -- Bhaskar > > On Fri, 2004-07-30 at 17:50, Daniel L. Johnson wrote: > > On Sun, 2004-07-11 at 06:47, Adrian Midgley wrote: > > > I've been asked for specific advice for a medical missionary intending to go > > > set up a clinic somewhere in the middle of Africa. > > > > > > I suspect that pencil and paper may be the most appropriate technology what > > > with power and so on... > > > > Way back in 1981, a little group of MIT guys formed Mark of the Unicorn > > and went on to write a word processor, FinalWord, that had one wonderful > > feature: It maintained a swap file, a text database that was created > > and maintained invisibly to the user, writing the current document to > > floppy every 1K bytes or whenever the keyboard was inactive for M > > seconds (M user-definable). If the power went out, as it very often did > > in the first 8 years I was a computer user, the doc was saved; worst > > case scenario, the swap file was corrupted, in which case you ran the > > recovery program to rebuild it. > > > > I can't tell you how many hours of re-writing this saved me back then, > > and I still use this little dos program for text creation because of > > this safety feature. > > > > Big programs need to have such disaster-recovery features built in as > > well, and this little note about Africa and unreliable power reminded me > > of this fact. > > > > Dan Johnson md > > >
