RotatingFileSink and the log filenames without extension

[fahrudinhalilovic]

After the new release of the library (12.0.0) this issue was resolved and the files from the previous application/service runs were taken into account for the maximum number of the files which can be generated for the RotatingFileSink. There is one more question -> if in the destination for the RotatingFileSink the filename has been specified which does not have an extension then this does not work - i.e. files generated from the previous runs start to "accumulate" once again. Is the desired behaviour? This is quite easy to reproduce with the following configuration:

quill::RotatingFileSinkConfig cfg;
cfg.set_open_mode('a');
cfg.set_rotation_max_file_size(1024); // in bytes
cfg.set_rotation_time_daily("00:00");
cfg.set_rotation_naming_scheme(quill::RotatingFileSinkConfig::RotationNamingScheme::DateAndTime);
cfg.set_max_backup_files(5);
cfg.set_overwrite_rolled_files(true);
cfg.set_remove_old_files(true);

auto rotating_file_sink_1 = quill::Frontend::create_or_get_sink<quill::RotatingFileSink>("<some_directory>/application", cfg);
auto rotating_file_sink_2 = quill::Frontend::create_or_get_sink<quill::RotatingFileSink>("<some_directory>/application.log", cfg);

In the case of the rotating_file_sink_1 previously generated files are not taken into account while for the rotating_file_sink_2 this works as expected with the 12.0.0 version of the library.

[sueun-dev]

Reproduced this on v12.0.0 and yeah, looks like a bug rather than intended. The no-ext path breaks recovery in _try_parse_rotated_file: it gates on candidate.extension() != base.extension(). Your rotated files get named application.20260622_... (stem + '.' + datetime), and std::filesystem reads that trailing .20260622_... as the extension. Base application has an empty extension, so every rotated file fails that check and never gets counted toward max_backup_files, which is why they keep piling up. With application.log the extension matches (.log == .log) so recovery works, matching what you saw.

So the workaround is exactly what you found: give it an extension. A real fix would derive the suffix from the base stem instead of fs::path::extension().

[fahrudinhalilovic]

For me, workaround is fine - I mean in 99% of the time, extension will be present anyway. It's just that someone might be a bit surprised when the files start "accumulating" if they forget to specify the filename with the extension. Maybe mentioning this in the official docs could be enough for this issue...

[apozzer305]

thanks for reporting, there is a fix in #939

[fahrudinhalilovic]

okay, so the fix is available from 12.1.0 if I see that correctly. thanks.