Community
Participate
Working Groups
See bug 170317 comment 16. There is a patch for correctly handling encoding of target link name. This should be reviewed/released. SymlinkTest.testSymlinkExtendedChars is currently failing in the builds, so I will disable it until I can review the patch and ensure the tests pass.
Perhaps the Runtime.getRuntime().exec() is the problem. I didn't find documentation what this does with respect to the encodings. I tested on a Redhat WS4 x86 box with the Sun 1.5 jvm and it worked fine. The links and files created by the test looked correct in an xterm (same as in the Java code). Changing the SymlinkTest.java encoding to UTF-8 might also help (currently it's ISO-8859-1). What os / arch / jvm do the build machines run? What's the file.encoding Java property (from Eclipse Help > About > Configuration)?
Setting Version=3.3, OS=Linux since that's the only where the tests were enabled.
Thinking again, without the mentioned patch it is expected behavior that the SymlinkTest.testSymlinkExtendedChars fails when the default encoding (system property file.encoding) is not UTF-8: Runtime.exec() creates the symlink with the default file.encoding, and the native code reads it as UTF-8 so they're not the same and the test fails. That's what the test was written for... looks like an excellent test of the test :-)
Strangely, the test doesn't fail on my Linux box even before I apply the patch. I.e., the exact code that fails on the test machine passes on mine. In any case, I'll apply this patch because it looks like a better fix (and contains various other good fixes to doc, attributes() method, etc).
I'm curious whether it'll work with the patch. FYI, I found this interesting: http://forum.java.sun.com/thread.jspa?threadID=682845&messageID=3979890 Looks like on Linux, the JVM default encoding is governed by the LANG or LC_ALL environment variables, though that's also not fully reliable. Perhaps your Linux box has it set differently than the build machine, or the build machine's VM is doing it differently. Or, the Runtime.exec( { "ln", "-s", tgt, src } ) fails on the build machine because the ln program misbehaves creating the link with special characters. This could be checked by putting a breakpoint in there and checking the junit-workspace/temp directory for what has been created (or not).
I released the patch to HEAD last night but it still failed. I'm going to disable the test for now to avoid disrupting the M5 release next week. Interestingly, the failure was not on the link target name, but on the resource info name: assertTrue(infoName.endsWith(specialCharName)); (line 339 in revision 1.5)
Hm.. when I remember right, this comes from IFileStore.childNames() which comes from java.io.File.list() -- on UNIX, the name attribute of IFileInfo is populated from Java and not overwritten by native code. Looks like given the encodings on the test machine, commands through Runtime.exec() produce files differently than reading them by java.io.File.list(). It might be helpful to see what the actual difference is -- was the String truncated, did it get any extra chars or was it just wrongly interpreted?
I'll add more debugging info to the test and try to track it down next week.
Not critical for M7. This is likely just an issue with the test.
(In reply to comment #1) > Perhaps the Runtime.getRuntime().exec() is the problem. It is on my platform. Links created during the test are corrupted. It's Mac OS X, 10.5.7. The file.encoding property is set to MacRoman. JVM is from Sun, 1.5.0_19.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
