Feature Requests item #1567331, was opened at 2006-09-28 14:36 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-22 09:26 Message: Logged In: YES user_id=341410 Originator: NO There are at least two ways to "solve" the "problem" regarding "what do we name the log after it is full". Here are just a few: 1) The 'being written to' log is X.log, the most recent 'finished' log is X.log.<maxcount-1>, it uses the reverse renaming semantic to what is already available. 2) The 'being written to' log is X.log, the most recent 'finished' log is the log just before a 'missing' log. Say you have .log, .log.1, .log.3; .log.1 is the most recent 'finished' log, and when .log is full, you delete .log.3, rename .log to .log.2, and start writing to a new .log ( (mod x) + 1 method ). Semantic #1 isn't reasonable when you have a large number of log files (that isn't infinite), just like the current semantic isn't reasonable when you have a large number of log files (even infinite), but #2 is reasonable (in terms of filesystem manipulations) when you have any number of log files. It is unambiguous to the computer, and can be made unambiguous to the user with a 'get log filenames' function that returns the chronological listing of log files (everything after the 'missing' file comes first, then the stuff before the 'missing' file, then the 'current' log). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-01-22 08:09 Message: Logged In: YES user_id=308438 Originator: NO Josiah - OK...suppose I use your semantics: Create log ... at rollover, log -> log.1, create log anew ... at rollover, log -> log.2, create log anew ... at rollover, log -> log.3, and the user has set a backup count of 3 so I can't do log -> log.4 - then I still need to rename files, it seems to me. If I don't, and say reuse log.1, then the user gets an unintuitive ordering where log.1 is newer than log.3 sometimes, but not ar other times - so your approach would *only* be beneficial where the backup count was infinite. For such scenarios, I think it's better to either use e.g. logrotate and WatchedFileHandler, or create a new class based on RotatingFileHandler to do what you want. Providing support for "infinite" log files is not a common enough use case, IMO, to justify support in the core package. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-20 10:39 Message: Logged In: YES user_id=341410 Originator: NO What about an optional different semantic for log renaming? Rather than log -> log.1, log -> log.<count>+1, so if you have log, log.1, log.2; log -> log.3 and log gets created anew. I've used a similar semantic in other logging packages, and it works pretty well. It would also allow for users to have an "infinite" count of logfiles (if that is what they want). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2007-01-15 08:44 Message: Logged In: YES user_id=308438 Originator: NO The problem with this is that on rollover, RotatingFileHandler renames old logs: rollover.log.3 -> rollover.log.4, rollover.log.2 -> rollover.log.3, rollover.log.1 -> rollover.log.2, rollover.log -> rollover.log.1, and a new rollover.log is opened. With an arbitrary number of old log files, this leads to arbitrary renaming time - which could cause long pauses due to logging, not a good idea. If you are using e.g. logrotate or newsyslog, or a custom program to do logfile rotation, you can use the new logging.handlers.WatchedFileHandler handler (meant for use on Unix/Linux only - on Windows, logfiles can't be renamed or moved while in use and so the requirement doesn't arise) which watches the logged-to file to see when it changes. This has recently been checked into SVN trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
