@francoispluchino what kind of a template path are you talking about exactly?

'C:\\path\\to\\section\\name.php' would be converted to C:path/to/section/name.php even with the old regex.

Yes the path is correctly converted by

$name = str_replace(':/', ':', preg_replace('#/{2,}#', '/', str_replace('\\', '/', $name)));

But with the new regex

if (!preg_match('/^(?:([^:]*):)?(?:([^:]*):)?(.+)\.([^\.]+)\.([^\.]+)$/', $name, $matches)) {

the result of match is true and not false (normally).

This gives a TemplateReference with a bundle name C defined by $matches[1].

It is not the case with the old pattern.

What I was saying earlier is that both regular expressions work the same with the example path I gave (both don't match 'C:\\path\\to\\section\\name.php'). See https://3v4l.org/DlsP3

It's not the case with:

$name = 'C:\\path\\to\\section\\name.html.twig';

That's what I was after (an example). What's the outcome you expect?

preg_match result:
0 not 1

matches result:

[]

not:

[
 "C:path/to/section/name.html.twig",
 "C",
 "",
 "path/to/section/name",
 "html",
 "twig"
]

The problem is with the file names with many dot.

see also #17777 which contains some more information how to reproduce this issue

@francoispluchino any idea why the name is normalised to C:path/to/section/name.php? I'm not a windows user but this seems wrong as it misses the / after C:.

No I haven't idea, but the bug is caused by the name with more dot, not by the drive (ex. name.html.twig).
With the old version, the normalization already used the format with only c:, and it was not a problem..

@francoispluchino I know that, just trying to understand why it's normalised to this form :) Thanks anyway!

@fabpot Why the TemplateNameParser normalize the path without slash after the letter of Windows drive? Is it expected, or it's a bug?

C:path/to/section/name.html.twig and not C/:path/to/section/name.html.twig.

@jakzal I think it is better to focus on the end of the regex pattern, which blocks the use of file names with more dots.

Template names starting with "@" are also broken (see ticket #17958). Are they also considered absolute paths, or should I reopen the other ticket?

@hcomnetworkers they're not considered absolute paths, but I'm fixing them as part of #17894 (that's why it's not merged yet).