When RotatingFileHandler.doRollover() raises an exception, it puts the handler object in a permanently failing state, with no way to recover using RotatingFileHandler methods.  From that point on, the handler object raises an exception every time a message is logged, which renders logging in an application practically useless.  Furthermore, a handleError() method has no good way of correcting the problem, because the API does not expose any way to re-open the file after doRollover() has closed it.

Unfortunately, this is a common occurrence on Windows, because doRollover() will fail if someone is running tail -f on the log file.

Suggestions:

- Make doRollover() always leave the handler object in a usable state, even if the rollover fails.

- Add a reOpen() method to FileHandler, which an error handler could use to recover from problems like this.  (It would also be useful for applications that want to re-open log files in response to a SIGHUP.)

Vinay, was this addressed?  I thought there was a similar issue.

I've added an _open() method to logging.FileHandler [checked into trunk]. This facilitates reopening by derived class error handlers.