Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Newsgroups: news.software.b Subject: Re: C News: batchrunning (on|off) perhaps ? Message-ID: <_60og2.zy2@smurf.sub.org> Date: 1 Dec 90 00:26:50 GMT References: <1990Nov27.161854.24449@robobar.co.uk> <1990Nov29.041256.26775@zoo.toronto.edu> Organization: University of Karlsruhe, FRG Lines: 26 In news.software.b, article <1990Nov29.041256.26775@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: < In article urlichs@smurf.sub.org (Matthias Urlichs) writes: < >Does the dbz database have a flag to indicate that the database has been < >closed cleanly? If not, it should probably be added..? < < Unfortunately, it's impossible to do right. I thought about this a bit, < but the combination of stdio buffering, buffer caches, and the Nightmare < File System make it virtually impossible to make such a flag trustworthy. < Well, I'm not using NFS, and an fflush() plus fsync() should take care of most cases. You wouldn't entirely eliminate the risk of getting a database marked clean in error, but it would be reduced. Given that crashing a system is also a low-probability event (or at least it should be), that might be enough. However, < However, there basically isn't much room for inconsistency. Particularly < if you are not using the in-core facility, writes go out immediately anyway. Good news. (On my site, INCORE is used with expire only, and with expire it doesn't matter if there's a crash.) -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/