Community
Participate
Working Groups
When running Bug_233939.testMultipleLinksToFolder() with Java 7 fragment on Windows 7 with admin privileges (the test needs to be enabled by commenting out isWindowsVistaOrHigher() at the beginning of the test), the test fails because of NPE: java.lang.NullPointerException at org.eclipse.core.tests.resources.ResourceTest.existsInWorkspace(ResourceTest.java:701) at org.eclipse.core.tests.resources.ResourceTest.assertExistsInWorkspace(ResourceTest.java:317) at org.eclipse.core.tests.resources.ResourceTest.assertExistsInWorkspace(ResourceTest.java:309) at org.eclipse.core.tests.resources.regression.Bug_233939.symLinkAndRefresh(Bug_233939.java:55) at org.eclipse.core.tests.resources.regression.Bug_233939.testMultipleLinksToFolder(Bug_233939.java:130) ...
The test can be fixed in DosHandler by using Files.exists(path, LinkOption.NOFOLLOW_LINKS) to correctly check the existence of the link instead of the link target. At the moment, the existence of the link is checked by Files.exists(path) which by default follows symbolic links. This seems to be wrong because we are interested in the existence of the link not the link target, but since the test passes on Linux, it needs more investigation to understand the difference.
Interestingly, when asked about the existence of the link, Linux native fragment answers by checking the existence of the link target. This results in a situation where symbolic links pointing at non-existing files/folders are not shown in Eclipse which is surprising, at least for me. Windows native fragment shows such links but they are not usable so it behaves in the same way as Windows Explorer. Martin, do you know if the Linux native fragment works correctly here?
Steps to reproduce the bug manually: 1. Create a project. 2. Create a folder in the project. 3. Create a symbolic link in the folder pointing at non-existing folder. 4. Refresh the project and expand all nodes. => The symbolic link is not shown at all when using Java 7 fragment but is shown when using Windows native fragment.
Fixed in master: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=b5621e7909df1848b272230ef9d00288ca652a58
(In reply to Szymon Ptaszkiewicz from comment #2) > Interestingly, when asked about the existence of the link, Linux native > fragment answers by checking the existence of the link target. Yes, I think it works correctly because the IFileInfo#exists() API had to retain the behavior that was originally observed from java.io.File#exists() before the native fragments were added. java.io.File#exists() would also return false for symlinks pointing to nowhere. In general, java.io.File would always follow symbolic links, and the EFS implementation (and therefore Eclipse Resource system) mostly resembles that concept.
(In reply to Martin Oberhuber from comment #5) > (In reply to Szymon Ptaszkiewicz from comment #2) > > Interestingly, when asked about the existence of the link, Linux native > > fragment answers by checking the existence of the link target. > > Yes, I think it works correctly because the IFileInfo#exists() API had to > retain the behavior that was originally observed from java.io.File#exists() > before the native fragments were added. java.io.File#exists() would also > return false for symlinks pointing to nowhere. > > In general, java.io.File would always follow symbolic links, and the EFS > implementation (and therefore Eclipse Resource system) mostly resembles that > concept. Thank you for clarification.
Verified in I20140429-2000.
