Harmony
  1. Harmony
  2. HARMONY-535

[classlib][luni] java.io.File doesn't properly work with the file names which have non-latin chars

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None
    • Environment:
      J9, Windows

      Description

      java.io.File doesn't properly work with the file names which has non-latin chars on Windows (I tried Russian) .

      Minimal test case:

      import java.io.File;
      import junit.framework.TestCase;

      public class FileEncodingTest extends TestCase {
      private File russianNamedDir;

      protected void tearDown() throws Exception

      { russianNamedDir.delete(); }

      public void testCreateNonLatinDirectory() throws Exception

      { russianNamedDir = new File("c:\\temp\\\u0440\u0443\u0441_dir"); //coded 'rus' in Russian transliteration. russianNamedDir.mkdirs(); assertTrue(russianNamedDir.isDirectory()); }

      }

      The very important thing here is that Control Panel > Regional And Language Options > Regional Options tab > "Standards and formats" setting is set to "English US". All other regional settings (location, language for non-unicode programs) are set to Russian. If I switch "Standards and formats" to Russian everything works fine.
      Same problem with other extended unicode chars.

        Issue Links

          Activity

          Hide
          Ilya Okomin added a comment -

          I would like to add, on DRLVM suggested test doesn't work no matter if "Standards and formats" option set to Russian or not.

          Show
          Ilya Okomin added a comment - I would like to add, on DRLVM suggested test doesn't work no matter if "Standards and formats" option set to Russian or not.
          Hide
          Tim Ellison added a comment -

          Problem is that we compute the properPath using byte[] rather than String representation of the path. Simple test shows different behavior on RI vs. Harmony:

          String fname = "C:\\temp\\\u0440\u0443\u0441";
          File f = new File(fname);
          String canonPath = f.getCanonicalPath();

          System.out.println(fname);
          System.out.println(canonPath);
          System.out.println("Equal = " + fname.equals(canonPath));

          Show
          Tim Ellison added a comment - Problem is that we compute the properPath using byte[] rather than String representation of the path. Simple test shows different behavior on RI vs. Harmony: String fname = "C:\\temp\\\u0440\u0443\u0441"; File f = new File(fname); String canonPath = f.getCanonicalPath(); System.out.println(fname); System.out.println(canonPath); System.out.println("Equal = " + fname.equals(canonPath));
          Hide
          Richard Liang added a comment -

          Hello Anton and Tim,

          I cannot reproduce this issue on revision r504840. Would you please help to verify whether it's still a problem? Thanks a lot.

          Best regards,
          Richard

          Show
          Richard Liang added a comment - Hello Anton and Tim, I cannot reproduce this issue on revision r504840. Would you please help to verify whether it's still a problem? Thanks a lot. Best regards, Richard
          Hide
          Tony Wu added a comment -

          Hi all,
          Both the tests above have passed on my laptop. And I believe it is duplicate to harmony-3656. would you pls close it?

          Show
          Tony Wu added a comment - Hi all, Both the tests above have passed on my laptop. And I believe it is duplicate to harmony-3656. would you pls close it?
          Hide
          Mikhail Markov added a comment -

          I've also just checked on my WinXP with russian locale: before H-3656 patch integration it really failed, but now it passes. So, seems like the issue is resolved and could be closed.

          Show
          Mikhail Markov added a comment - I've also just checked on my WinXP with russian locale: before H-3656 patch integration it really failed, but now it passes. So, seems like the issue is resolved and could be closed.
          Hide
          Mikhail Markov added a comment -

          As HARMONY-3656 was finally fixed, this issue could also be closed.
          Could someone from committers do this please? Thanks!

          Show
          Mikhail Markov added a comment - As HARMONY-3656 was finally fixed, this issue could also be closed. Could someone from committers do this please? Thanks!
          Hide
          Tim Ellison added a comment -

          Closing as duplicate of HARMONY-3656.

          Show
          Tim Ellison added a comment - Closing as duplicate of HARMONY-3656 .

            People

            • Assignee:
              Richard Liang
              Reporter:
              Anton Avtamonov
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development