-
Bug
-
Resolution: Fixed
-
P2
-
5.0
-
b50
-
generic
-
windows_2000
The j2se workspace directory test/sun/misc/URLClassPath contains non-ASCII
named files. When tests are run, more non-ASCII files are copied into
the JTwork directory.
These files cannot be deleted using either the MKS or Cygwin rm commands,
causing build scripts to break.
test/sun/misc/URLClassPath $ rm -rf JTwork
rm: cannot remove directory "JTwork/classes/sun/misc/URLClassPath": The directory is not empty.
rm: cannot remove directory "JTwork/classes/sun/misc": The directory is not empty.
rm: cannot remove directory "JTwork/classes/sun": The directory is not empty.
rm: cannot remove directory "JTwork/classes": The directory is not empty.
rm: cannot remove directory "JTwork": The directory is not empty.
zsh: exit 1 mksenv rm -rf JTwork
sun/misc/URLClassPath $ rm *.class
rm: cannot unlink entry "‘%<†+O.class": The system cannot find the file specified.
zsh: exit 1 mksenv rm *.class
Worse, it appears that this most evil file is not even used.
The code appears to be commented out.
// can't test the following class unless platform in unicode locale
// Class class2 = acl.findClass("\u624b\u518c");
// System.out.println("class2 = "+class2);
Also, the test case does not take proper precautions against being
run outside of the jtreg harness. Some tests are designed to be
run this way, but if ClassNameCharTest.sh is run this way, it
might modify the filesystem outside of the test directories.
E.g. this code
cd ${TESTCLASSES}
${TESTJAVA}${FS}bin${FS}jar xvf *.jar
might cd to the HOME directory and possibly explode some jar files there,
possibly overwriting the user's files.
Very, very evil, that.
It is possible to write tests for non-ASCII file names.
Check out
test/java/lang/ProcessBuilder/Basic.java
Check out this technique from
test/tools/javac/unicode/SupplementaryJavaID6.java
class \ud801\udc00 {
void \ud801\udc01() {
// If Java can create the strangely named class file,
// then Java can delete it, while `rm' might be unable to.
new java.io.File(this.getClass().getName() + ".class")
.deleteOnExit();
System.out.println("success");
}
}
###@###.### 2004-04-28
named files. When tests are run, more non-ASCII files are copied into
the JTwork directory.
These files cannot be deleted using either the MKS or Cygwin rm commands,
causing build scripts to break.
test/sun/misc/URLClassPath $ rm -rf JTwork
rm: cannot remove directory "JTwork/classes/sun/misc/URLClassPath": The directory is not empty.
rm: cannot remove directory "JTwork/classes/sun/misc": The directory is not empty.
rm: cannot remove directory "JTwork/classes/sun": The directory is not empty.
rm: cannot remove directory "JTwork/classes": The directory is not empty.
rm: cannot remove directory "JTwork": The directory is not empty.
zsh: exit 1 mksenv rm -rf JTwork
sun/misc/URLClassPath $ rm *.class
rm: cannot unlink entry "‘%<†+O.class": The system cannot find the file specified.
zsh: exit 1 mksenv rm *.class
Worse, it appears that this most evil file is not even used.
The code appears to be commented out.
// can't test the following class unless platform in unicode locale
// Class class2 = acl.findClass("\u624b\u518c");
// System.out.println("class2 = "+class2);
Also, the test case does not take proper precautions against being
run outside of the jtreg harness. Some tests are designed to be
run this way, but if ClassNameCharTest.sh is run this way, it
might modify the filesystem outside of the test directories.
E.g. this code
cd ${TESTCLASSES}
${TESTJAVA}${FS}bin${FS}jar xvf *.jar
might cd to the HOME directory and possibly explode some jar files there,
possibly overwriting the user's files.
Very, very evil, that.
It is possible to write tests for non-ASCII file names.
Check out
test/java/lang/ProcessBuilder/Basic.java
Check out this technique from
test/tools/javac/unicode/SupplementaryJavaID6.java
class \ud801\udc00 {
void \ud801\udc01() {
// If Java can create the strangely named class file,
// then Java can delete it, while `rm' might be unable to.
new java.io.File(this.getClass().getName() + ".class")
.deleteOnExit();
System.out.println("success");
}
}
###@###.### 2004-04-28
- relates to
-
JDK-5043585 test/sun/misc/URLClassPath test files are still undeletable on Windows
-
- Resolved
-
-
JDK-4957669 REGRESSION:create a socket with a Japanese hostname throws IllegalArgumentExcept
-
- Resolved
-