#702 Report contains wrong filenames when using symbolic links

[Maarten Coene]

Hi,

I use PMD on unix. My source files are in fact symlinks. If I run PMD on my sources, the produced XML report contains the name of the original file and not the name of the link. In my opinion, it should contain the name of the link.

For instance:

say I have a directory /usr/maarten/src which has some source files. These files are symbolic links to other files.

/usr/maarten/src>ls
Source1.java --> /usr/home/svn/Source1.java
Source2.java --> /usr/home/svn/Source2.java

When I run PMD on my /usr/maarten/src directory, the filename in the produced XML report is "/usr/home/svn/Source1.java" instead of the expected "/usr/maarten/src/Source1.java"

I think this is caused by using "getCanonicalPath()" in the "FileDataSource".

regards,
Maarten

[Romain PELISSE]

Logged In: YES
user_id=1679130
Originator: NO

Hi Maarten,

Symbolic links is *nix specific features that is not supported by File implementation. I read some stuff several weeks about the "New Java API for I/O" ( package java.nio ) that allowed access to system specific features, however the real question is : "Is this really a bug ? Is default Java behaviour a "bad one" ? Personnaly, i don' think so...

I think this problem is more of "feature request" than a bug, isn't it ?

[Maarten Coene]

Logged In: YES
user_id=178745
Originator: YES

The File API tells that the getCanonicalPath() will resolve symbolic links on unix platforms. It has nothing to do with NIO or things like this. It has always been like this.

I simply think PMD should be carefull when using the getCanonicalPath(). Other tools doesn't do this neither because it's confusing and gives problems.

For instance, if I would compile my sources, the compiler would tell me that /usr/maarten/src/Source1.java has compilation errors, not that /usr/home/svn/Source1.java has errors. The same is true for Ant: it never translates a symbolic link to its origin. I think PMD should do the same.

Another thing is that earlier versions of PMD didn't use the getCanonicalPath() method, so these versions didn't resolve the symbolic links. I don't know exactly in which PMD version this behaviour changed.

Maarten

[Romain PELISSE]

Logged In: YES
user_id=1679130
Originator: NO

"The File API tells that the getCanonicalPath() will resolve symbolic links
on unix platforms. It has nothing to do with NIO or things like this. It
has always been like this."

Yes, that what i meant. I spoke about NIO as a possible way to "detect" symbolic links and allow some kind of way to parametize this ( ie <pmd useSymbolicLinks="true"... for instance). That's why i suggest it could be a feature request. Sorry, i wasn't clear enough.

[Xavier Le Vourch]

Logged In: YES
user_id=1373398
Originator: NO

I'm the one who added the call to getCanonicalPath() a while back :( and although the log comment doesn't say it, the reason was that if you run pmd with a relative path, the output can be "weird". For instance, from the bin directory, running:

./pmd.sh ../src text ../rulesets/basic.xml -targetjdk 1.5

will generate output with lines similar to:

/home/xlv/dev/pmd/Current/bin/../src/net/sourceforge/pmd/PMD.java:581 Avoid empty catch blocks

The intent was to replace Current/bin/../src with Current/src so maybe the canonical call should only be done on the pmd arguments and not the full path so that ../src will be translated as
/home/xlv/dev/pmd/Current/src but symbolic links within the src tree wouldn't be translated?

Xavier

[Maarten Coene]

Logged In: YES
user_id=178745
Originator: YES

Maybe you can use something like org.apache.tools.ant.util.FileUtils.normalize(String file) to do what you want. This way, the symbolic links aren't resolved, but your "/../" problem is solved.

Cfr. http://www.dpml.net/api/ant/1.6.5/org/apache/tools/ant/util/FileUtils.html#normalize(java.lang.String)

Maarten

[Romain PELISSE]

Could you confirm this is still an issue with the lastest release ? (4.3)

If not, please, close the bug :)