When creating a new environment on a hard drive with insufficient free
disk space, the error code returned seems to be DB_RUNRECOVERY.
Wouldn't it make more sense to return ENOSPC ?

Andi..

I forgot to mention that this is running Berkeley DB 4.4.16 on Mac OS X
10.4.3.

Andi..

Hi Andi

We don't want applications to have to interpret and handle every
possible error that could be returned by the system, so we aggregate
those errors into classes of failure -- in this case, "panic", or
DB_RUNRECOVERY.

Regards,
Ron

Ron wrote:
Well, I sure expect to know why something fails when the disk is full.
As a matter of fact db->put() will fail with ENOSPC in that situation.
Given that ENOSPC is returned by some APIs (good), I'd love it for all
APIs that can fail that way to consistently return it.
When creating the environment, typically after our application is first
installed, I need to be able to report to the end user that their disk
is full as opposed to telling them 'panic', "run recovery".
I cannot check disk space after the fact because the disk is actually
not full because the file creation filling it failed.
The only heuristic I can come up with is to verify that the env files
are not there (or some missing) and then 'guess' that they couldn't be
created because of a full disk. If Berkeley DB knows the actual reason
for failure, I sure want it to tell me instead if having me try to
figure it out after the fact using uncertain, brittle, heuristics.

Thanks

Andi..

Are you running with verbose error messages turned on?

Ron

Ron wrote:
No, how would I do that ?

I only interpret the error code returned as an int to me from the C
API.
env->open() is not documented to return ENOSPC.

Andi..