Module: logging
OS: Windows XP

When using the RotatingFileHandler, the logging cras when i open the Logfile in an Texteditor.

I think there is a Problem in renaming the Files, while it's open in the Texteditor.

Traceback (most recent call last):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 76, in emit
    if self.shouldRollover(record):
  File "C:\Programme\Python26\lib\logging\handlers.py", line 150, in shouldRollo
ver
    self.stream.seek(0, 2)  #due to non-posix-compliant Windows feature
ValueError: I/O operation on closed file

I don't think this error can be avoided, though if you set logging.raiseExceptions to False then the exception won't be raised, though the handler won't produce any more output, either.

I don't believe this is a logging bug - you're not supposed to keep files open in the editor while you're still rotating, as the library assumes that all rotated files are under its control for deleting and renaming.

If you need different functionality, subclass the handler and implement your own handling logic to deal with open files; it's not appropriate to do this in the standard library as there's no "obvious" way to handle locking of files which are supposed to be under the library's control.

Based on the above reasoning, I'm marking this as "invalid" and "pending" to see what your response to my comment is. If I don't hear any more about this for a week or so, I'll mark this issue as closed.

Closing, as I said I would, since no feedback has been received for a week.

I hit that problem too (Python 2.6.5). We have a Windows service application (daemon, in Unix parlance). This is written in Python and uses RotatingFileHandler to rotate files when they exceed 1MB. We look at the files for debugging. For a live view of log entries, we use less.exe in follow mode. 

If the rotating log handler hits the size limit while the current log file is watched, it throws an exception and logging is broken henceforth. Restarting the service while less.exe is still running does not help, it hits the same exception right from the outset.

Since we cannot stop users from looking at the log files, and we cannot have our service application die by user interaction, this is a serious problem.

I am confused by the statement that "you should not look at the files as long as they are under the library's control". As I understood, on rotating, the oldest file will be deleted, all others will be renamed, and a new file will be created. No file will remain untouched. As far as the human log reader is concerned, rotation can happen at any time, so all log files are under control of the library for their entire life.
If that's true, why bother writing them in the first place? :-)

The root problem is that RotatingFileHandler cannot rename the file while less.exe has it open. Under Unix-like file systems, this problem may not appear: Renaming an open file works, and the file descriptor held by less.exe remains valid. The logger is free to create another file with the same name. Under Windows, files and directory entries are more closely related. Hence, the error "The process cannot access the file because it is being used by another process". I do not know if it is possible to work around this.

Comments are appreciated. RotatingFileHandler looks like a good match for long-running service applications. If this issue remains unresolved, it is not. A word of warning in the docs seems appropriate in this case.

There have been no widespread reports of rotating file handlers being unusable under Windows. This is a Windows limitation that generally needs to be worked around, it's not limited to logging applications only.

It's possible to copy a set of rotated files to another location for more leisurely examination, though that could also cause failures depending on how the files are opened for copying.

If this option is not open to you, you can still use a rotating file handler base class, but just reimplement the doRollover() method to implement any other strategy you like of dealing with files held open by other processes. This was suggested in an earlier response - is there any reason it wouldn't work for you?

Thank you for the reply. I'll look into subclassing, but I am not convinced that there is a way to fix this: The basic problem is that one viewer has a file open, and the logger would like to start a new file with the same name.

What would work, is to generate file names based on (say) the current day, as in Logfile-20110502.txt. This design avoids the problem that we're rolling over to files of the same name, but it is a different beast from RotatingFileHandler.

That said, I think this issue should be reopened: RotatingFileHandler is a part of the standard library, and Windows is a supported platform.
If the logger crashes because somebody is looking at a log file, this is a valid bug.

There is already a TimedRotatingHandler for generating file names based on dates. However, it rotates based on time, not size.

I don't agree that this is a bug just because Windows is a supported platform; the problems in this issue are due to a shortcoming in Windows. There is no universally acceptable "obvious" strategy to deal with this shortcoming. If you know of one, please elaborate.

You make no comment about my suggestion to copy files to another location before viewing.

This is not fundamentally a logging issue; any attempt to call os.rename or os.unlink will fail on Windows if the file is kept open in, say, a text editor. Logging cannot take an obvious alternative path in this case, and for that reason, IMO this issue should remain closed. 

I do not recommend raising an issue against the os module, either ;-)