Hi Victor,

A couple of points:

1. On Windows, you can't rename files which are open, so the strategy of closing after renaming doesn't work.

2. Using the alternative strategy (on failure, open the file with the current mode, else open with 'w') - if the exception is re-raised in doRollover, the message about to be logged is not logged (because doRollover is called before logging the message). So, nothing gets written to the log file: each attempt to emit() fails because of the exception in doRollover.

If, on the other hand, the exception is not re-raised, then the write of the logged message proceeds as expected, but the log file then grows without limit - definitely a Bad Thing as it could then interfere with normal program operation (e.g. when the disk fills up).

So, I think the better solution is for the user who has this kind of problem to subclass the handler (as it cannot do what it's meant to do, for reasons beyond its control) and to override handleError and attempt recovery based on the circumstances of the exception (for example in your case, switch the handler's base file name to some writable location).

I'm also not sure if disabling rotation on error is useful or not: the conditions causing the error might be removed externally (e.g. write protection reinstated, file locks released).

I'm not sure why, on logging errors, you would find that your application starts to fail randomly: I've tried to ensure that logging problems interfere with application operation as little as possible. Of course external factors might be affecting both application operation and logging operation, correlation != causation :-)

What do you think?