can.LogReader error on opening "filename.with.too.many.dots.blf"

[ghost]

Describe the bug

in python3 repl

>> can.LogReader("./2021.11.23.test.blf") 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/mnt/c/Users/username/Documents/various/python-can/can/io/player.py", line 87, in __new__
    raise ValueError(
ValueError: No read support for this unknown log format ".11.23.test.blf"

To Reproduce

Open a log file with more then one period in it.

Expected behavior

The file should be opened as a blf file
If the file is renamed to "test.blf" the conversion works properly

Additional context

OS and version: Ubuntu20.04 in WSL Linux TL0213507 4.4.0-19041-Microsoft #1237-Microsoft Sat Sep 11 14:32:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux
Python version: python 3.8.10
python-can version: python develop commit 2e24af0

[Tbruno25]

I can take this issue.

[Tbruno25]

I'm unable to reproduce on Ubuntu 20.04.3 LTS.

Maybe this only occurs when using WSL? Unfortunately I don't have a Windows system available to test.

edit: my mistake, was on main not develop

[felixdivo]

I can reproduce it on Python 3.10 @ Win 10 (not WSL, but classic installation) on develop. I think the problem is here:

suffix = "".join(s.lower() for s in pathlib.PurePath(filename).suffixes)

We should probably just replace it with suffix = pathlib.PurePath(filename).suffix.

[felixdivo]

In any case, we should add a regression test for this. Strange that this never occurred ...

[felixdivo]

Incidently, that was the case some while ago, and apparently it was changed ... (I found this PR (#895) while compiling the new changelog.)

Git blame revealed that #1138 eventually changed it in order to detect files like *.asc.gz. Seems like that change was not tested with this (not so corner) case.

So maybe the fix is not as simple, but it should still be fairly straightforward to fix, I guess.

[felixdivo]

We could replace GzipASCReader by a GzipReader that just consumes the last suffix and then uses LogReader internally again to determine the reader once compression was removed (from the file and file name). This would actually be a nice feature since other readers would be supported too.

[Tbruno25]

@felixdivo took a first pass at this in #1221 -- let's continue the discussion there.

[felixdivo]

Thanks @Tbruno25 for tackling this!

[pierreluctg]

This bug this I have introduced 👎 is also affecting the LogWritter.

See https://github.com/hardbyte/python-can/blob/develop/can/io/logger.py#L88