
<html><body>> <br>> The program I've been developing obviously have to be 100% stable :)<br>> <br>> You can't be 100% stable on a multi-user system unless you use a write<br>where<br>> you flush the buffer to the disc and then do the error checking - even<br>after<br>> you have written your buffer another program of higher priority might fill<br>> the disk so your buffer can't get to it and your error will only come at<br>> your next write. <br>> <br>> The safest writes are to space that you already have allocated - random<br>> writes. That is what databases do. In the case of a log-file, make your<br>file<br>> circular and pre-allocate it a certain size, then you will overwrite old<br>> messages, but you will never fill up the disk.<br>> <br>> This is a bit more work for people who read the log-file later, but you<br>can<br>> write a small reader to do it for them. There are lots of ways of doing<br>> this, but to be safe it is best to write your new record to the circular<br>> file - making sure it writes through any system buffers (a write with<br>wait)<br>> - then write the record number to the start of the file. That way your<br>> log-file reader can easily show the last n records which are usually the<br>> ones of interest.<br>> <br>> On an msdros system you can make it fairly friendly by giving your<br>circular<br>> file an extension that you map to your reader - then people using it don't<br>> need to be aware of how its done.<br>> <br>> <br><br>Thanks for that response, I guess is isn't possible to do on a<br>multi-user system as you said. However a circular file would mean you'd<br>only have a log-file history of length x ... Interesting way of doing<br>it, would mean you'd never be able to view any logs beyond x since they<br>don't exist.<br><br>Not necessarily. Good practice, say on a security logging system, is to use<br>two circular log files. When one fills up you switch to the other - then you<br>compress and back up the full log-file to tape/CD ROM/ftp server and send an<br>alarm if you find that the log-files are filling up to quickly. That way one<br>security denial of service (causing log-files to fill up discs or wrap<br>around) is avoided. Over time you can size your log files so that they<br>automatically back up and switch every day or two.<br><br>A really sensible approach on a unix system is to treat syslog this way and<br>use syslog calls for all your messages. That means that they are interleaved<br>with system and other messages (easy to disentangle with greps) so that you<br>can get the full context of an error. If everybody did that then there<br>wouldn't be all those hundreds of irritating log files all over the place!</body></html>