> Hmmm, gbak has no way of knowing beforehand what the volume of data will
> be. How would you suggest it could be made possible?
> how could gbak tell whether all of the disk space available at the
> beginning would still be there at the end?

I would assume gbak writes to the backup file line by line as it works its
way through the data. I would also assume gbak uses standard file io
functions, like fwrite(). These proven functions return a status, so it
should require no more than a couple of lines of of code to detect a failed
write and abort the entire backup process since it would be corrupt anyway.

> The only way YOU can anticipate the conditions and protected your
> automated
> procedures is to monitor the sizes of database files and backup files over
> time and to treat disk capacity as something you have to make provision
> for, not entrust to pot luck.

I, as a developer, always try and make things user friendly. Imagine
microsoft had the same attitude. Copy a file from disk c to d. If it says
"copy OK" I trust it and delete the original without another thought,
because I know windows did what it said it did, and if it didnt it would say
so.

IMHO the success message on failure should be considered a bug.

Gary