Name | Version | Release Date | Size | MD5 |
---|
Most times the logs on the JNIOR get overwritten with data and the relevant data to a time period that you wish to debug is no longer available. The Log Archiver application uses the built-in archiving capabilities to extend the amount of storage capabilities of the log files.
When a log file has reached its limit, the current version of the log gets renamed to .log.bak. A new log file is started. The Log Archiver watches for the .log.bak files. When it sees that one was created it will add it to an archive. The archive that is used is based on the file name. There are a set of system files that will be added to a system.zip archive. Other files will be added to an archived based on the part of the the file name that comes before and underscore ‘_’ or dash ‘-‘. If an underscore or dash is not found then the full name without the extension is used.
When a file is added to the archive it will be added as a .log file with a date formatted string representing the last modified date.
The archives will grow until they reach a maximum size. This maximum size is configurable in the registry by modifying the AppData/LogArchiver/MaxArchiveSizeInKB
key.
Once the maximum size the application will attempt to remove file entries until the size falls below the maximum. The entries that are removed are the oldest entry that has more than two versions in the archive. The following example shows a system.zip archive with some older entries. Most likely when a new entry is added, an access-*.log will be removed.
The exception occurs if a jniorboot.log or a web.log file is added. Then the oldest version of those files would be removed.
This feature only works when log files use the .bak concept. System log files have always employed the .bak file concept. Our built-in, add-on and custom applications have been using a rolling log concept. We will convert the logging used in applications to .bak usage as we release updates.