WARN: Cannot find the file '...' in module '...' base dir '...', skipping violations. #1651
Comments
|
@rudolfgrauberger thanks for reporting the issue.
This is a known issue:
Someone another solution? @Bertk think you are also using this. How you are doing this? |
|
@rudolfgrauberger @guwirth short comment from my side: for the implementation of the check, whether the given path lies inside of the give project/module, we rely completely on the SonarQube plugin API. public InputFile getInputFileIfInProject(SensorContext sensorContext, String path) {
...
final InputFile inputFile = sensorContext.fileSystem().inputFile(sensorContext.
fileSystem().predicates().hasPath(path));
if (inputFile == null) {
LOG.warn("Cannot find the file '{}' in module '{}' base dir '{}', skipping violations.",
path, sensorContext.module().key(), sensorContext.fileSystem().baseDir());
notFoundFiles.add(path);
}
...
}The internal implementation of the search predicates is (as far I see) string based. See DefaultFileSystem for more details. This might explain why expected equality doesn't work in case of symbolic links, case-insensitive file systems etc. You might want to file an issue against https://github.com/SonarSource/sonarqube (probably somewhere in the depths of https://jira.sonarsource.com/). P.S. I believe, we shouldn't implement any workarounds as part of sonar-cxx. |
|
@ivangalkin problem is that VS on Windows never works without correction. So not sure if we should not correct it inside the VS sensor? |
When I see this here and see that they did it in the scanners themselves (Pull Request and Commit), I don't think they're changing anything.
I don't think there's a realistic alternative. If we solve this similar to their commit with Path.toRealPath(), we would have solved both problems (symbolic links and case-insensitive file systems). Edit: I'm definitely gonna try it. It sounds like a cleaner solution/workaround than renaming the paths with a script before. Are you interested? If yes, then I can make a pull request afterwards. Then you can still see if it suits you and you want to have it. |
|
@rudolfgrauberger sonar-cxx is not a stand-alone application; it is a plugin, which is executed inside of the framework; so there are two things running independently
We had this very issue with symbolic links. Please see #1574/ #1575. I believe the solution with I did a quick draft of the possible solution. Please take a look at the implementation (#1653). Not sure, if we always have to double-check the result of searching-for-realpath with searching-for-just-given-path. @guwirth what do you think? @rudolfgrauberger could you please test the solution on you setup. You can find the build artifacts under https://ci.appveyor.com/project/SonarOpenCommunity/sonar-cxx/builds/21369802/artifacts |
|
@ivangalkin Thank you very much for this explanation, it is very helpful. I will test this solution and post my answer to #1653 |
* introduce the fallback for the lookup of `InputFile`s: try it with the Path::realPath() resolves SonarOpenCommunity#1651
* introduce the fallback for the lookup of `InputFile`s: try it with the Path::realPath() resolves SonarOpenCommunity#1651
Description
If the source code is in subdirectories, the comparison of the paths is case-sensitive. (Also on Windows)
The output of MSBuild contains all paths in lowercase (see buildlog.log in log section). However, the project contains a subdirectory "Sources" in which all source files are located. This means that the files cannot be found.
Steps to reproduce the problem
Expected behavior
That the compiler sensor finds the file and analyzes it. Under Windows the upper and lower case "actually" doesn't matter.
If I have seen this correctly here (#155), then it was already a topic once. Could it be that it was lost during the last refactoring (#1180)?
Actual behavior
Because the file is not found, it is not analyzed.
Known workarounds
Not good, but works...
Rename folder to lower case
LOG file
stdout
buildlog.log
Related information
The text was updated successfully, but these errors were encountered: