gcovr not scanning files if source files located below virtual path

[fglohr]

Describe the bug gcovr not scanning files if source files located below symlink path

To Reproduce Steps to reproduce the behavior:

1. Create symlink link on the source files using command mklink /J %SUBST_DIR% %WORKSPACE_DIR%
2. chdir to the created symlink and run gcovr --html-details
3. result : no error during run, but coverage reported in html wrong

When running directly in WORKSPACE_DIR coverage report in html is correct

Desktop (please complete the following information):

• OS: Windows
• GCC version 6.3.0
• GCOVR version 5.1

[Spacetown]

If no --filter is used the default is a filter for the realpath (%WORKSPACE_DIR%) of the root directory (%SUBST_DIR%) but the path from gcov is only normalized. Can you try to set `--filter=%WORKSPACE_DIR:=/%" to explicit filter the files in the target of the junction?

You can also use the option --verbose to see the used filters and how the files are filtered.

[simonCor]

I have seen the the same behaviour with virtual drives on Windows (e.g. subst I: C:\sources).

The problem seeems, that the AbsolutFilter runs the match function with the path parameter converted by os.path.realpath. While the pattern which it is matched against is not run through os.path.realpath.

The result then is, that I:\ and C:\sources are compared and filtered from the result.

IMHO this can not just be fixed by applying os.path.realpath to pattern because this may also contain regex. I think applying realpath here is the problem.

There also seems to be a problem in the same region with the DirectoryPrefixFilter().

(Please ignore my patch - this is not the whole story)

[simonCor]

We currently use a workaround: We call gcovr from a python script there we convert all pathes by os.path.realpath bevore sending them to gcovr.

small addition: We also have to use --filter os.path.realpath(Source_folder)

[Spacetown]

If the function https://github.com/gcovr/gcovr/blob/10a8a17eb748abc3c823dbbb43f7b7f752d415de/gcovr/utils.py#L263-L265 is changed to

 def match(self, path: str):
     return super().match(realpath(path))

symlinks in the other direction won´t work anymore (see tests filter-relative-lib...).

[simonCor]

Yeah I think a fix is not trivial because this is a niche problem and may have other implications...

How about a detection of the problem and a warning message with a hint how to work around it as first addition?

(Of course a fix would be preferable...)

[Spacetown]

Something like if the root is a symlink use the realpath?

[simonCor]

Hm something like: If the --filter parameter is set implicitly with root, check "is os.path.realpath(root) != os.path.abspath(root)"

"It seems, that your root is on a virtual drive/symlink on windows. This may result in problems. See bug "link to this bug""

[Spacetown]

If a warning is enough, yes.

[whart222]

I'm not sure I understand the logic of adding a warning. I'm working in a context where my home directory is symlinked, and I don't get to work around that. So, a warning doesn't help me; gcovr won't work for me on this machine.

Does this change break other use cases? I don't see it.

Is there a motivation for adding a separate option to change this configuration?

[Spacetown]

I need to check this. The logic of the filters was already in place when I joined the project. I think #712 is correct and we need to check the broken tests.