The Readme file, the troubleshooting file and the CLI & GUI guides have been updated according to the recent changes, and now contain information on the new export options.
The new error that may occur to prevent accidentally overwriting an existing export file has also been added to the troubleshooting file.
Additionally, the exporter has been improved and now also removes the existing export's asset files if they're at their default location.
The setting on whether the existing export search is enabled or not has been made configurable in both the CLI and the GUI (instead of being hardcoded):
- A search-existing-exports option has been added to all CLI export commands, which enables the existing export search for the respective command.
- A Search for existing exports option has been added to the GUI settings, which enables the existing export search for exports.
Additionally, there have been several minor improvements:
- The ConsoleProgressLogger has been fixed to interpolate given messages (previously, the square brackets in the default export file names could cause an exception).
- The names of existing channel exports in log messages have been enclosed by quotation marks.
- The setting on how to handle existing export files has been renamed from prev-export / Previous Export to export-exists / Export Exists.
Previously, an existing export could only be detected if it existed at the current file target path.
However, if the name of the channel, the channel parent or the guild has changed or if the default file name formatting has changed, the existing export's file name would be different, and it could therefore not be detected.
Therefore, the option to explicitly search for the existing export in the target directory has been added.
If it's activated (and there's no existing export at the current file target path), all file names in the target directory will be compared to a regex that matches any file name the channel export (with the same date range) might have had in the past.
If several existing exports have been detected, an error is logged and the channel export is aborted. Otherwise, it continues as before (only additionally moving the existing export files to the to the new file paths if they should be appended).
Whether this new option is activated is currently hardcoded.
The enum FileExistsHandling has been renamed to ExportExistsHandling to clarify that the setting applies to existing exports in general.
If file names of a directory are needed, they are collected lazily and stored for future use in other channel exports to avoid unnecessary I/O operations.
Several bugs related to appending empty channel exports have been fixed:
- Previously, the partition index hadn’t been adapted if the existing channel export had been empty. This had resulted in an uncaught exception as the target file had already existed.
- Previously, the HTML last message detection hadn’t worked if the export had been empty, resulting in an uncaught exception.
- Previously, empty TXT exports had been detected as message containing because the footer hadn’t been taken into account. This had resulted in an uncaught exception as no valid timestamp could have been retrieved.
- Previously, empty TXT & CSV exports would have been detected as message containing if they had contained enough empty lines. This has been fixed by testing whether the respective file has enough non-empty lines in a functional and lazy way.
Additionally, there have been multiple other improvements:
- The CSV last message detection has been improved to now use the last non-empty line. Previously, it wouldn’t have worked (and thrown an exception) if there had been any trailing empty lines.
- The info messages that a channel export is being appended had previously not been logged if the export had been empty. Therefore, new specific info logs have been added for this situation.
- If an empty channel had previously been exported and is still empty, the export will now be aborted (and a respective new info message will be logged).
- A comment has been added to the HTML template to prevent it from being changed without corresponding changes in the HTML last message detection.
An export progress logger has been added to the exporter. It provides a consistent way to log the entire process of an export, meaning all status updates of each of the exported channels. It also allows to count the different results of the individual channel exports and can provide a summary of them.
There are two subclasses: The ConsoleProgressLogger logs the status updates with colors on the console while the SnackbarProgressLogger logs them in the GUI snackbar.
Previously, two exceptions had been used to signalize "warnings" and "errors", and respective messages had been displayed (GUI) respectively collected and displayed after the export finished (CLI) upon catching them.
Individual counts had been used to display an export summary message after the export finished.
The new logging system has numerous advantages:
- It allows logging status updates during a channel export (without having to abort it). Therefore, it also allows for informational messages, success messages and (non-urgent) warning messages to be logged.
- It doesn't use exceptions in situations without any need for exceptional handling, resulting in cleaner code.
- It logs all these messages instantly on both the CLI and GUI, instead of only displaying the log messages after the export finished.
- It removes duplicated code structures between the CLI and GUI parts; replacing individual logging / counting code with a general consistent logger / counter, which improves the code quality.
- This also makes it handle the logging much more consistently: Not only are the messages logged in the general export codebase, but their appearance and formatting are now defined together in a single place, making the logging system much more consistent and maintainable.
Using the new system, many informational messages and warning messages have been added to the export process. This particularly includes messages about the handling of existing export files that had been added provisionally with Console.WriteLine.
The existing messages have also been made more consistent with each other.
Furthermore, the logging of success messages has been added to the exporter. This allows the user to better watch the progress in the GUI and solves the problem that the progress hadn't been watchable in the CLI if parallel exports had been enabled.
The export summary message has also been massively improved:
While previously, it had just contained the number of channels that have been successfully exported, the handling of existing export files has added other possible export results, specifically the channel having already been exported and being appended or overwritten successfully, and the channel having already been exported and not having been appended as there are no new messages.
Therefore, the export summary has been changed to contain the number of channel exports that resulted in each occurring export result.
This also means that it now contains the number of empty new channel exports (which had previously not been included).
The setting the exporter uses to handle existing export files has been made configurable in both the CLI and the GUI (instead of being hardcoded):
- A prev-export option has been added to all CLI export commands, which sets the file exists handling for the respective command.
- A Previous Export option has been added to the GUI settings, which sets the file exists handling that's used for exports.
Previously, existing export files had just been overwritten by a new export.
This has been changed; instead, there are now several possible options on how to explicitly handle existing export files:
- Abort aborts the export if the channel had previously been exported.
- Overwrite removes the existing export before exporting the channel again.
- Append appends the existing export, which means that only messages after the last export will be exported.
The option that's used if a previous export is detected is currently hardcoded.
A safeguard has been added to prevent the exporter from accidentally overwriting any existing files.
Additionally, the creation of a Snowflake from a timestamp has been improved: If a Snowflake will be used to determine the messages starting at the given timestamp, it now won't precisely represent that timestamp anymore, but instead be the latest possible Snowflake just before that timestamp.
This is necessary to prevent the first Discord message in that specific millisecond from being excluded (which may have previously happened).
