Subj : Committing file changes
To : Coridon Henshaw
From : George White
Date : Sat Aug 19 2000 02:59 pm
Hi Coridon,
On 14-Aug-00, Coridon Henshaw wrote to David Noon:
<snip>
DN>> Moreover, if your data resources are critically important then
DN>> you should be handling any traps that occur in your program and
DN>> cleaning up the critical data resources in an orderly manner.
DN>> This is far and away the most professional approach to the
DN>> situation. About the only things you can't handle are kernel
DN>> level traps and power outages.
CH> The problem I ran into was that the kernel trapped (for reasons
CH> unrelated to this project) a few hours after I wrote an article
CH> into the article database. Since database was still in open (I
CH> leave the article reader running 24x7), the file system structures
CH> were inconsistant enough that CHKDSK truncated the database well
CH> before its proper end point. As you say, catching exceptions
CH> wouldn't help much here
CH> My database format and engine implementations are robust enough to
CH> cope with applications dying unexpectedly without finishing write
CH> operations; they're not robust enough to handle boot-up CHKDSK
CH> removing 80Kb of data from the end of a 100Kb file
DN>> In your situation, I would have used the second facility before
DN>> considering any intermediate commits.
CH> It's not intermediate commits I need: what I need is some way to
CH> flush out write operations made to files which might be open for
CH> days or weeks at a time
The only reliable way I know of is _NOT_ to keep the files open but to
open and close them as needed. It is the _only_ way I know which is
guaranteed to update the directory information (Inode under *NIX) so
that a chkdsk won't cause you that sort of grief. In a similar
situation I ended up opening and closing the file during normal
operation to ensure the on-disk information and structures were
updated. Originally I opened the file on start-up and kept it open.
George
--- Terminate 5.00/Pro
* Origin: A country point under OS/2 (2:257/609.6)
