Hi,

How do you check for file errors such as "Disk Full" before attempting to write out a file to disk ?
You can easily check if a file exists with the fileExists function... Can something similar be done for other file errors ?

cheers
James

You can check with diskfree() how much space is left on a disk

Peter

Well the program I'm developing is irc services, any particular way you'd reccomend recoding it so it doesn't crash because of a 'Disk Full' error ?
I actually found out that my disk got full because iroffer (www.iroffer.org) has a bug in it and went into an infinite loop today 100% cpu usage writing out data to a log file using up my entire disk drive.

But this eventually caused services to crash because it couldn't write out it's own log...

cheers
James

You can turn of io-checking and check the result of ioresult

{$I-}
 writeln(flog,logmessage)
{$I+}
if ioresult0 then
 writeln(stderr,'Error writing to disk');

Is this considered good programming practise ? Reason I ask is that I used to use borland's turbo pascal years ago and am aware of ioresult but am interested in how people before me have done it (eg: on linux systems).

The program I've been developing obviously have to be 100% stable :)

cheers
James

-----Original Message-----
From:
On Behalf Of James Mills
Sent: 05 May 2003 12:12
To:
Subject: Re: [fpc-pascal]File errors

Peter Vreman wrote

> On Mon, May 05, 2003 at 11:35:14AM +0200, Peter Vreman wrote: >> > Hi, >> > >> > How do you check for file errors such as "Disk Full" before

attempting

Is this considered good programming practise ? Reason I ask is that I used to use borland's turbo pascal years ago and am aware of ioresult but am interested in how people before me have done it (eg: on linux systems).

The program I've been developing obviously have to be 100% stable :)

You can't be 100% stable on a multi-user system unless you use a write where you flush the buffer to the disc and then do the error checking - even after you have written your buffer another program of higher priority might fill the disk so your buffer can't get to it and your error will only come at your next write.

The safest writes are to space that you already have allocated - random writes. That is what databases do. In the case of a log-file, make your file circular and pre-allocate it a certain size, then you will overwrite old messages, but you will never fill up the disk.

This is a bit more work for people who read the log-file later, but you can write a small reader to do it for them. There are lots of ways of doing this, but to be safe it is best to write your new record to the circular file - making sure it writes through any system buffers (a write with wait)
- then write the record number to the start of the file. That way your log-file reader can easily show the last n records which are usually the ones of interest.

On an msdros system you can make it fairly friendly by giving your circular file an extension that you map to your reader - then people using it don't need to be aware of how its done.

Thanks for that response, I guess is isn't possible to do on a multi-user system as you said. However a circular file would mean you'd only have a log-file history of length x ... Interesting way of doing it, would mean you'd never be able to view any logs beyond x since they don't exist.

cheers
James

You can use exceptions:
...
try
writeln(flog,logmessage)
except
if sometheng goes wrong :(
end;
...

jk

[ Charset ISO-8859-1 unsupported, converting... ]

Can be dangerous in multi tasking and/or multi user system. Also that doesn't keep track of e.g. the reserved rootspace on unix.

Best way is to check ioresult after writing each block to see if it is zero?

Oh right. I forgot FPC had support for exceptions. Afterall it is an OO Language :P haha

Thank you, try except is probably more what I want.

cheers
James

Or use a try except ?

cheers
James

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

The program I've been developing obviously have to be 100% stable :) You can't be 100% stable on a multi-user system unless you use a write

where

you flush the buffer to the disc and then do the error checking - even

after

file

circular and pre-allocate it a certain size, then you will overwrite old messages, but you will never fill up the disk. This is a bit more work for people who read the log-file later, but you

can

write a small reader to do it for them. There are lots of ways of doing this, but to be safe it is best to write your new record to the circular file - making sure it writes through any system buffers (a write with

wait)

circular

file an extension that you map to your reader - then people using it don't need to be aware of how its done.

Thanks for that response, I guess is isn't possible to do on a multi-user system as you said. However a circular file would mean you'd only have a log-file history of length x ... Interesting way of doing it, would mean you'd never be able to view any logs beyond x since they don't exist.

Not necessarily. Good practice, say on a security logging system, is to use two circular log files. When one fills up you switch to the other - then you compress and back up the full log-file to tape/CD ROM/ftp server and send an alarm if you find that the log-files are filling up to quickly. That way one security denial of service (causing log-files to fill up discs or wrap around) is avoided. Over time you can size your log files so that they automatically back up and switch every day or two.

A really sensible approach on a unix system is to treat syslog this way and use syslog calls for all your messages. That means that they are interleaved with system and other messages (easy to disentangle with greps) so that you can get the full context of an error. If everybody did that then there wouldn't be all those hundreds of irritating log files all over the place!

Standard fileoperations don't raise exceptions. That is for higher level constructs (like FCL file streams).

If basic block I/O would use exceptions, that would make it slow.

basic IO also generates exceptions when SysUtils is used. The normal runtime errors will then be mapped to their corresponding exceptions.

Then why did Jilani Khaldi suggest using exceptions ?

cheers
James

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Or use a try except ?

Don't forget to include the SysUtils unit, if you're gonna use exceptions. (Converts all runtime errors to exceptions).

Really ? Thank you, That's rather usefull to know. I would then be able to use exceptions then without any performance penalty dispite what Peter wrote...

cheers
James

Typo, Marco wrote rather...

sorry
James

Thank you

James

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Then why did Jilani Khaldi suggest using exceptions ?

By experience ;)
I have always used exceptions to control I/O and they worked always fine as expected.

jk

Jilani Khaldi wrote

>Then why did Jilani Khaldi suggest using exceptions ? By experience ;) I have always used exceptions to control I/O and they worked always fine as expected.

No it's ok. Was just getting a little confused over the discussion.

cheers
James

They do if you have the sysutils unit in your uses statement (sysutils converts rtes to exceptions).