Managing local bug reports by bug reports file rotation

EurekaLog can store bug reports locally - in a text file. This file is used both as a log and as a database. Each exception will be appended to the local bug report file. Some users want to know how to set up bug report file rotation. Log rotation is the automated process of managing log files to prevent them from growing too large, which can impact system performance and storage. It involves doing something with old log files (compressing, archiving, renaming, or deleting) and creating a new, empty one to continue recording new events.

This article will discuss what options you have for EurekaLog's local bug reports file.

Why you may want a bug reports file rotation

First of all - EurekaLog is a tool which is designed to collect bug reports from PCs of your users/clients. It means its primary purpose is to send bug reports to you via some sending method - be it a simple e-mail or a dedicated bug tracker. Therefore, local bug reports file is completely useless to you (the developer), as you typically don't have any remote access to PCs of your users/clients. In other words, local bug reports file rotation is not a problem for like 90% of EurekaLog's users, because you will be receiving bug reports and not using the local bug reports file in the first place.

Therefore, if you set up sending in EurekaLog, you will probably want to disable storing local bug reports completely. Thus, avoiding the rotation problem altogether.

However, there are cases when you do need to use local bug reports:

1. Some of EurekaLog's users use it in a way it was not designed to perform (at least it was not EurekaLog's main purpose). Specifically, they use EurekaLog as a replacement for IDE's debugger - to perform a local debugging/troubleshooting on their development machines. Naturally, they will use the local bug reports file and not set up any sending;
2. Some of EurekaLog's users develop apps which are designed to be run in private corporate environments. Corporate environments may have strict rules on network connectivity, so setting up sending is not viable/possible. Naturally, they will also use the local bug reports file and not set up any sending. For example, an app may be configured to store bug reports on a shared network drive, which can be accessed by you (the app's developer).

Once local bug reports file is enabled/set up - there may be two completely different reasons why you may want to implement a bug report file rotation:

1. Removing obsolete bug reports. For example, you probably are not interested in bug reports from 5-10 years ago, as these will likely be irrelevant. That is - assuming you release updates to your app regularly.
2. Managing size of bug report files. This matters most for apps which run 24/7 non-stop, such as services. If your service is configured to continue to run after crashing with exception - your local bug reports file may grow fast.
   This reason is probably irrelevant for non-service apps, because you will likely to wipe obsolete bug reports (as in #1 above) long before file size become a problem.

Note:

If you need to implement any custom way to deliver reports to yourself (be it saving into a specific folder, inserting into database, or something else) - it is better to implement this as "sending", rather than "saving" (for example, saving/inserting bug report in the OnExceptionNotify event handler). That way you will actually be sending reports, so you can disable the local bug reports file - thus having all sending rules applied and without worrying about local bug reports file rotation in the first place.

Bug reports are not log entries

EurekaLog does not have any sort of automated process, which is typically scheduled to run at regular intervals (e.g., hourly, daily, weekly) or when a file reaches a certain size. That is because local bug reports file contains bug reports - a valuable information. It is not a log - which contains auxilary (less important) info. That is why EurekaLog will never delete bug report files without your explicit command. It is up to you to decide which bug reports are important and which ones are no longer relevant.

Managing size of bug report files

This is the most simple and straightforward way: you don't care about importance of bug reports, you just want to avoid unlimited file size grow. Perhaps, you are using local bug reports file as a backup to sending, so you are not really worried about losing precious reports.

If this is the case - there are the "Max. reports in one file" and "Do not save duplicate errors" options. You can limit how much bug reports can a single local bug reports file hold by altering these options. While you can't specify a file size limit in bytes, but you do this by specifying file size limit in reports. That way you will use a single local bug reports file, and will limit its size to some reasonable value of your choice.

There is also the "Delete file at startup" option, which can be useful in some cases.

Removing obsolete bug reports

If you don't care about limiting file size, but rather want to tidy up your reports - you may want to delete old reports which lost their importance.

EurekaLog has the "Delete file at version change" option, which will create a fresh local bug reports file once you deploy a new version of your application. This option requires you to embed version information into your executable, as well as increase it for each build/release. This option works well if you release new builds/versions of your app more or less regularly, and your users/clients/customers upgrade your app. This option will be useless if you very rarely make new releases, or if your users/clients/customers prefer to stay at single version of your app.

There is also IDE's "Tools" / "EurekaLog" / "Bug reports" / "Delete old bug reports..." menu item, which you can invoke manually as often as you like:

Bug reports cleanup from IDE

There is no other option which can delete local bug reports file due to it obsolesence. However, what you can do is to have multiple local bug reports files. For example, if you are developing a service application, you may want to use a new local bug report file for each day, week or month. Other possible alternative is to have one file per each bug (so the single file will contain multiple reports of the same bug). You can do either of these by using either variables or events:

Using variables to rotate the local bug report file

The default output for local bug report file is
%AppData%\Neos Eureka S.r.l\EurekaLog\Bug Reports\%_ThisModuleName%\
which will be expanded to something like
C:\Users\your_user_name\AppData\Roaming\Neos Eureka S.r.l\EurekaLog\Bug Reports\Project1.exe\Project1.el
at run-time. Notice how it will be the same file name for each bug/exception.

You can alter local bug report file name to something like
%AppData%\Neos Eureka S.r.l\EurekaLog\Bug Reports\%_ThisModuleName%\%_ThisModuleName%_%DateFmt%.el
which will be expanded to
C:\Users\your_user_name\AppData\Roaming\Neos Eureka S.r.l\EurekaLog\Bug Reports\Project1.exe\Project1.exe_20251031.el
at run-time. The important part: the expansion of environment variables happens during exception's processing. In other words, the local bug report file name will be calculated for each exception, resulting in multiple local bug report files if your application will run for multiple days.

Obviosly, if you want your bug report file to contain multiple bug reports at once - you need to increase the above mentioned "Max. reports in one file" limit, because the default value is 1 (a bug report file can store only one bug report).

Notice how you can change both folder name only (when ending with trailing path delimiter) or file name (when ending with file extension), so you can have one file per day or one folder per day.

You can also use something like
%AppData%\Neos Eureka S.r.l\EurekaLog\Bug Reports\%_ThisModuleName%\%_ThisModuleName%_%_BugID%.el
which will be expanded to
C:\Users\your_user_name\AppData\Roaming\Neos Eureka S.r.l\EurekaLog\Bug Reports\Project1.exe\Project1.exe_00CAB105.el
at run-time. That way you will have a standalone local bug report file for each bug/exception.

Or you can even combine the two together like so:
%AppData%\Neos Eureka S.r.l\EurekaLog\Bug Reports\%_ThisModuleName%\%DateFmt%\%_ThisModuleName%_%_BugID%.el
resulting in file names like
C:\Users\your_user_name\AppData\Roaming\Neos Eureka S.r.l\EurekaLog\Bug Reports\Project1.exe\20251031\Project1.exe_00CAB105.el

Using events to rotate local bug report file

There may be cases when you want to have a logic, which can't be implemented with environment variables. For example, if you want a new local bug report file for each month, but there is no environment variable that defines "a month of bug's occurence". In this case: you can use event handlers.

There is the OnCustomFileName event handler. You may assign your custom code to perform modification of the local bug report file name. You will be insterested in the AFileType = ftSavedBugReport case:

uses
  DateUtils,      // for YearOf and MonthOf
  EEvents,        // for RegisterEventCustomFileName
  EException,     // for TEurekaExceptionInfo
  EConsts,        // for EEurekaLogReportExt
  ETypes,         // for TEurekaLogFileType
  ECompatibility; // for YearOf and MonthOf on IDEs which do not have the DateUtils unit

// Alter local bug reports file name in any way we want
procedure ChangeLocalBugReportFileName(const ACustom: Pointer; 
  AExceptionInfo: TEurekaExceptionInfo; 
  const AFileType: TEurekaLogFileType; 
  var AFileName: String; 
  var ACallNextHandler: Boolean);
begin
  // Is this a local bug reports file name?
  if AFileType = ftSavedBugReport then
    // If yes - then change it
    // This code is just an example
    // Replace it with your own code
    AFileName := ExtractFilePath(AFileName) + // folder
                 Format('%s_%d_%d%s',         // file
                   [ExtractFileName(AExceptionInfo.ExceptionModuleName),
                    YearOf(AExceptionInfo.Time),
                    MonthOf(AExceptionInfo.Time),
                    EEurekaLogReportExt]);
end;

initialization
  // Ask EurekaLog to use our code to customize local bug reports file name
  RegisterEventCustomFileName(nil, ChangeLocalBugReportFileName);
end.

This code will produce file names like
C:\Users\your_user_name\AppData\Roaming\Neos Eureka S.r.l\EurekaLog\Bug Reports\Project1.exe\Project1.exe_2025_10.el

Naturally, you can do literally anything with the local bug reports file name when you are using an event handler.

Obviosly, if you want your bug report file to contain multiple bug reports at once - you need to increase the above mentioned "Max. reports in one file" limit, because the default value is 1 (a bug report file can store only one bug report).

Performing the actual rotation

While both methods discussed above will spawn a new local bug reports files from time to time (based on the conditions that you set) - they will not delete any old files. That is because EurekaLog does not know if you are interested in, say, bug reports from yesterday or not. It is up to you to decide which bug report files are qualified for deletion.

If you are running a normal application (not a service) - then you can perform the check on startup. If you are running a service application - then you may be interesting in performing the check, say, once per 100 exceptions:

uses
  EEvents,    // for RegisterEventExceptionNotify
  EException, // for TEurekaExceptionInfo
  ESysInfo;   // for ExpandEnvVars

// Remove old local bug reports files
procedure LocalBugReportsFilesCleanup; overload;
var
  Folder: String;
begin
  // Change the target folder for your specific location
  Folder := ExpandEnvVars('%APPDATA%\Neos Eureka S.r.l\EurekaLog\Bug Reports\');

  // Write here your code to cleanup old local bug reports files
  // ...
end;

var
  // Counter on how many unhandled exceptions were processed
  // In other words, how many bug reports were created
  GProcessedExceptionsCount: Integer;

// Will be called by EurekaLog for each unhandled exception
procedure LocalBugReportsFilesCleanup(const ACustom: Pointer;
  AExceptionInfo: TEurekaExceptionInfo;
  var AHandle: Boolean;
  var ACallNextHandler: Boolean); overload;
const
  // Customize this constant to your liking
  MaxExceptionsBetweenCleanups = 100;
begin
  // If there were enough exceptions...
  if GProcessedExceptionsCount > MaxExceptionsBetweenCleanups then
  begin
    GProcessedExceptionsCount := 0;
    // ...perform the cleanup
    LocalBugReportsFilesCleanup;
  end;
  Inc(GProcessedExceptionsCount);
end;

initialization
  // Perform the cleanup on startup:
  LocalBugReportsFilesCleanup;
  // Ask EurekaLog to perform the cleanup on exceptions:
  RegisterEventExceptionNotify(nil, LocalBugReportsFilesCleanup);
end.

How to implement the cleanup is up to you and it highly depends on how you organize your reports. For example, if you spawn a new local bug report file each day, you may enumerate all files and delete ones from yesterday or ones older than 1 year. You can extract the date part from a file name (if it is present) to get a sense on when this file was created. Surely, you can also use file's creation or modification date - assuming you are sure file dates were not tampered with.

If you spawn a new local bug report file for each bug/exception, you may collect/group these files into folders corresponding to dates, so you can wipe individual folders (older than X days) instead of files.

Here is an example of how your cleanup code might look like:

uses
  EEvents,        // for RegisterEventExceptionNotify
  EException,     // for TEurekaExceptionInfo
  ESysInfo,       // for ExpandEnvVars
  EConsts,        // for EEurekaLogReportExt
  ETools,         // for BuildFileList and GetFileCreation
  ETypes;         // for amSuperSetOf

// Remove old local bug reports files
procedure LocalBugReportsFilesCleanup; overload;
var
  Folder: String;
  FileName: String;
  Files: TStrings;
  Today: TDateTime;
  FileCreated: TDateTime;
  X: Integer;
const
  MaxAgeInDays = 365;
begin
  // Change the target folder for your specific location
  Folder := ExpandEnvVars('%AppData%\Neos Eureka S.r.l\EurekaLog\Bug Reports\%_ThisModuleName%\');

  // Write here your code to cleanup old local bug reports files
  // The code below is just an example
  // Replace it with your own code

  Today := Now;
  Files := TStringList.Create;
  try
    // Enumerate all local bug report files in the mentioned folder
    AdvBuildFileList(Folder + '*' + EEurekaLogReportExt,
                     faAnyFile, Files, amSuperSetOf,
                     [flFullNames, flRecursive]);
    // Check each found bug report file
    for X := 0 to Files.Count - 1 do
    begin
      // Get file's properties
      FileName := Files[X];
      if not GetFileCreation(FileName, FileCreated) then
        FileCreated := Today;

      // If the file is too old - delete it
      if DaysBetween(Today, FileCreated) > MaxAgeInDays then
        DeleteFile(FileName);
    end;
  finally
    FreeAndNil(Files);
  end;
end;

This code will delete all local bug reports files in the specified folder which are older than 365 days (1 year). If you wish to use a different logic to wipe files (say, wipe files from an older version of your app, wipe files for a fixed bug/exception, or anything else) - you would need to change or adjust this code.


See also:

• Additional downloads for EurekaLog (contains a sample bug reports cleanup tool)
• Managing bug reports in EurekaLog
• How to write code with EurekaLog?
• How to register en event handler?
• How to register event handler for leaks?
• How to add/save exception to a log?
• How to send/upload exception to a file/DB/folder?
• How to save report instead of sending it?
• How to send reports automatically?
• How to send bug report via my own code?
• Implementing offline storage for bug reports

Download EurekaLog | Purchase License | Contact Support