Community
Participate
Working Groups
I get test failures when running on Windows 7. For SymlinkTest#testSymlinkEnabled: We support sym links on this platform but the test asserts that we don't, so the test is wrong. For SymlinkResourceTest: the mklink command is failing. From some quick reading, it appears it requires administrator privileges, so the test should probably just be disabled for this case. testSymlinkEnabled(org.eclipse.core.tests.filesystem.SymlinkTest) junit.framework.AssertionFailedError: null at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertFalse(Assert.java:34) at junit.framework.Assert.assertFalse(Assert.java:41) at org.eclipse.core.tests.filesystem.SymlinkTest.testSymlinkEnabled(SymlinkTest.java:344) testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) junit.framework.AssertionFailedError: createSymLink: java.io.IOException: Cannot run program "mklink" (in directory "C:\1target\junit-workspace\Project0\a"): CreateProcess error=2, The system cannot find the file specified at org.eclipse.core.tests.harness.CoreTest.fail(CoreTest.java:63) at org.eclipse.core.tests.harness.CoreTest.createSymLink(CoreTest.java:228) at org.eclipse.core.tests.internal.localstore.SymlinkResourceTest.mkLink(SymlinkResourceTest.java:43) at org.eclipse.core.tests.internal.localstore.SymlinkResourceTest.createBug232426Structure(SymlinkResourceTest.java:58)
Created attachment 184404 [details] Fix for the first problem
In the end there was a total of five test failures: testSymlinkEnabled(org.eclipse.core.tests.filesystem.SymlinkTest) testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) testAttributeSymlink(org.eclipse.core.tests.resources.ResourceAttributeTest) testBug(org.eclipse.core.tests.resources.regression.Bug_233939) testMultipleLinksToFolder(org.eclipse.core.tests.resources.regression.Bug_233939)
Szymon P. has Windows 7 around.
Created attachment 187995 [details] patch v2 for the first problem (requires bug 335864 fix) Attached patch can be applied when the fix for bug 335864 is checked in. I also see 5 test failures when enabling "isWindowsVistaOrHigher()" in isTestablePlatform() so I've left that commented out for now. Will need some investigation in what respect symlinks are different on Windows than UNIX. Quite likely it's due to bug 317786 -- Windows treats attributes of a symbolic link as referring to the link itself, whereas UNIX refers to the link target. So, fixing this bug quite likely depends on the decision in bug 317786 (which in some sense affects API).
FWIW, with the fix for bug 335864 applied (which fixes link creation in general -- see the comment there how to run with elevated privileges) I see 5 different tests fail when "isTestablePlatform" is extended to Windows 7: testBrokenSymlinkAttributes testRecursiveSymlink testSymlinkAttributes testSymlinkPutReadOnly testSymlinkPutExecutable As mentioned in comment 4, I believe that these fail due to the different link attribute semantics in windows (but 317786, or a property of the OS).
*** Bug 336659 has been marked as a duplicate of this bug. ***
Martin's patch v2 committed to HEAD.
testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) testBug(org.eclipse.core.tests.resources.regression.Bug_233939) testMultipleLinksToFolder(org.eclipse.core.tests.resources.regression.Bug_233939) It looks like a problem with symlink target paths. There are Unix paths in these tests e.g. ../b and should be ..\b rather. Szymon P. will help me to investigate it tomorrow.
Created attachment 191673 [details] Patch v3 The patch fixes the problem with paths mentioned in comment 8. There is one remaining test to be fixed: testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) It seems that the refresh is stuck there in some refreshing loop.
Patch v3 committed.
(In reply to comment #9) > The patch fixes the problem with paths mentioned in comment 8. There is one > remaining test to be fixed: > > testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) We need to disable this test on Hudson Windows 7 at eclipse.org. Once it is disabled it does not block bug 295393 anymore. I raised a separate bug 340834 to fix testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest).
There are 4 tests that require admin rights to pass: - testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) - testAttributeSymlink(org.eclipse.core.tests.resources.ResourceAttributeTest) - testBug(org.eclipse.core.tests.resources.regression.Bug_233939) - testMultipleLinksToFolder(org.eclipse.core.tests.resources.regression.Bug_233939) Hudson at eclipse.org does not run tests as administrator. All mentioned tests are disabled there though. If these tests are run on Win7 with admin rights, only testBug232426(org.eclipse.core.tests.internal.localstore.SymlinkResourceTest) fails, but there is a separate bug 340834 for it.
(In reply to comment #4) > Will need some investigation in what respect symlinks are different on Windows > than UNIX. Quite likely it's due to bug 317786 -- Windows treats attributes of > a symbolic link as referring to the link itself, whereas UNIX refers to the > link target. > > So, fixing this bug quite likely depends on the decision in bug 317786 (which > in some sense affects API). Martin, it looks that this is not just a problem of Eclipse API but also Java API. In bug 340834 we found that there is a difference in behavior between java.io.File#getCanonicalPath() on Windows and on Unix.
