Rolling count added amidst the extension

[Falco20019]

Description
If a file name contains multiple dots, the rolling is added before the last dot instead of the first one.

Reproduction

• Add a configuration with .File("MyFile.ext1.ext2", fileSizeLimitBytes: 1, rollOnFileSizeLimit: true, retainedFileCountLimit: 10)
• Add two log entries (doesn't matter)
• See two files like MyFile.ext1.ext2 and MyFile.ext1_001.ext2

Expected behavior

• See two files like MyFile.ext1.ext2 and MyFile_001.ext1.ext2

Relevant package, tooling and runtime versions
Serilog.Sinks.File 6.0.1

Additional context
We added GZip hook and changed the file extension to .clef.gz and therefore we now have .clef_xxx.gz files, which our tooling is not fine with. Technically this is correct and the default behavior of Path.GetExtension, but it would be great to have it configurable (directory + file name + file extension) as the PathRoller already does internally support it.

[nblumhardt]

Thanks for the note; as you've mentioned, the current behavior is correct. The presence of dots.in.filenames.ext means there's no automatic way to designate more than the final dotted component as belonging to the extension.

It's a reasonable thing to want to do, but probably niche enough that adding specific APIs for it would be unappealing.

Although there have been a lot of (rejected 😓) requests to add configurable rolling policies, I don't think anyone's done the legwork so far to:

a) enumerate all of the requested scenarios to date (perhaps building a matrix of required rolling policy features for each scenario),
b) figure out where the cleanest cut point internally would be to extract the current path/interval handling code, and
c) figure out how this could slot into the file sink's API.

For example, if we were to extract a RollingPolicy or IRollingPolicy type, and add a WriteTo.File() overload that accepts an instance of the rolling policy instead of various rolling-related params, would the rolling policy be broad enough to cover a large range of scenarios? And if so, would the amount of code required for implementing a new policy be reasonable?

There's a good chance that we'd be stuck between underpowered rolling policies vs overcomplicated policy implementation, but if someone's interested in taking a look anyway it seems like a reasonable thing for us to investigate.