Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5039471

test/sun/misc/URLClassPath test files are undeletable on Windows

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P2
    • 5.0
    • 5.0
    • core-libs
    • b50
    • generic
    • windows_2000

    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

      Attachments

        Issue Links

          Activity

            People

              ywangsunw Yingxian Wang (Inactive)
              martin Martin Buchholz
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: