JDK-5039471 : test/sun/misc/URLClassPath test files are undeletable on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: generic
  • Submitted: 2004-04-28
  • Updated: 2004-05-04
  • Resolved: 2004-05-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b50Fixed
Related Reports
Relates :  
Relates :  
Description
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

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b50 tiger-beta2
14-06-2004

EVALUATION Yes. the class files need to be deleted because they are replaced by a jar file. ###@###.### 2004-04-29
29-04-2004