TrueZIP
  1. TrueZIP
  2. TRUEZIP-288

Windows UNC path names not always resolved correctly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: TrueZIP 7.5.5, TrueZIP 7.6, TrueZIP 7.6.1
    • Fix Version/s: TrueZIP 7.6.2
    • Component/s: TrueZIP Driver FILE
    • Labels:
      None
    • Environment:

      Windows

      Description

      The following code will result in an java.lang.IllegalArgumentException exception when using TrueZIP in combination with Java 1.7 (the path is assumed to be valid):

      TFile tfile = new TFile("\\\\hostname\\share
      test.zip");
      System.out.println( tfile.length() );

      results in:

      Exception in thread "main" java.lang.IllegalArgumentException: URI authority component has undefined host
      at sun.nio.fs.WindowsUriSupport.fromUri(Unknown Source)
      at sun.nio.fs.WindowsFileSystemProvider.getPath(Unknown Source)
      at java.nio.file.Paths.get(Unknown Source)
      at de.schlichtherle.truezip.fs.nio.file.FileController.<init>(FileController.java:50)
      at de.schlichtherle.truezip.fs.nio.file.FileDriver.newController(FileDriver.java:31)
      at de.schlichtherle.truezip.fs.FsAbstractCompositeDriver.newController(FsAbstractCompositeDriver.java:33)
      at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:59)
      at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:63)
      at de.schlichtherle.truezip.fs.FsDefaultManager.getController(FsDefaultManager.java:51)
      at de.schlichtherle.truezip.file.TFile.getController(TFile.java:1495)
      at de.schlichtherle.truezip.file.TFile.getController(TFile.java:1490)
      at de.schlichtherle.truezip.file.TFile.length(TFile.java:2070)

      More surprisingly, when using Java 1.6 this error does not occur. Instead I get the result I desire.

      Executing the following code will produce the expected result on my machine both for Java 1.6 AND 1.7:

      File file = new File("\\\\hostname\\share
      test.zip");
      System.out.println( file.length() );

      So as far as I can tell there seems to be a bug in TrueZIP. I also tested the latest TrueZIP revision (5541). This revision yields the same results.

        Activity

        Hide
        qui.tiqe added a comment -

        On my computer the above test application indeed yields the expected results (both with JDK 1.7.0_05 and 1.7.0_06). So I did some additional tests. As it turns out, the problem only occurs if there is an underscore in computer name. So "file://computer/share/" works, but "file://computer_name/share/" does not. However, as stated before, "file:////<path>" always works. And, this is also how Java 7 seems to do it.

        Try:

        File file = new File("//localhost/c$");
        System.out.println( file.toURI().toString() );

        The output will be:

        file:////localhost/c$/

        So I hope I have provided two compelling reasons to make the change. Actually, it is more like reverting a previous change as the code that solves the above issue used to be present in de.schlichtherle.truezip.fs.nio.file.FileController:

        [code]
        FileController(final FsModel model) {
        super(model);
        if (null != model.getParent())
        throw new IllegalArgumentException();

        URI uri = model.getMountPoint().toUri();
        if ('
        ' == separatorChar && null != uri.getRawAuthority()) {
        try

        { // Postfix: Move Windows UNC host from authority to path // component because the File class can't deal with this. // Note that the authority parameter must not be null and that // you cannot use the UriBuilder class - using either of these // would result in the authority property of the new URI object // being equal to the original value again. // Note that the use of the buggy URI constructor is authorized // for this case! uri = new URI( uri.getScheme(), "", TWO_SEPARATORS + uri.getAuthority() + uri.getPath(), uri.getQuery(), uri.getFragment()); }

        catch (URISyntaxException ex)

        { throw new AssertionError(ex); }

        }

        this.target = Paths.get(uri);
        }
        [/code]

        Show
        qui.tiqe added a comment - On my computer the above test application indeed yields the expected results (both with JDK 1.7.0_05 and 1.7.0_06). So I did some additional tests. As it turns out, the problem only occurs if there is an underscore in computer name. So "file://computer/share/" works, but "file://computer_name/share/" does not. However, as stated before, "file:////<path>" always works. And, this is also how Java 7 seems to do it. Try: File file = new File("//localhost/c$"); System.out.println( file.toURI().toString() ); The output will be: file:////localhost/c$/ So I hope I have provided two compelling reasons to make the change. Actually, it is more like reverting a previous change as the code that solves the above issue used to be present in de.schlichtherle.truezip.fs.nio.file.FileController: [code] FileController(final FsModel model) { super(model); if (null != model.getParent()) throw new IllegalArgumentException(); URI uri = model.getMountPoint().toUri(); if (' ' == separatorChar && null != uri.getRawAuthority()) { try { // Postfix: Move Windows UNC host from authority to path // component because the File class can't deal with this. // Note that the authority parameter must not be null and that // you cannot use the UriBuilder class - using either of these // would result in the authority property of the new URI object // being equal to the original value again. // Note that the use of the buggy URI constructor is authorized // for this case! uri = new URI( uri.getScheme(), "", TWO_SEPARATORS + uri.getAuthority() + uri.getPath(), uri.getQuery(), uri.getFragment()); } catch (URISyntaxException ex) { throw new AssertionError(ex); } } this.target = Paths.get(uri); } [/code]
        Hide
        Christian Schlichtherle added a comment -

        You mean de.schlichtherle.truezip.fs.file.FileController?! Thank you for reminding me where I had seen this issue before. Unfortunately the URI class has lots of bugs and I obviously worked around it for the JSE 6 driver, but somehow thought it had been fixed in JSE 7 (maybe it has only been partially fixed and that's why it used to work for me).

        I'll incorporate the workaround from the JSE 6 driver to the JSE 7 driver. Sorry for this annoyance.

        Show
        Christian Schlichtherle added a comment - You mean de.schlichtherle.truezip.fs.file.FileController?! Thank you for reminding me where I had seen this issue before. Unfortunately the URI class has lots of bugs and I obviously worked around it for the JSE 6 driver, but somehow thought it had been fixed in JSE 7 (maybe it has only been partially fixed and that's why it used to work for me). I'll incorporate the workaround from the JSE 6 driver to the JSE 7 driver. Sorry for this annoyance.
        Hide
        Christian Schlichtherle added a comment -

        Changeset: 4d62a89c0ec3
        Author: Christian Schlichtherle <christian AT schlichtherle DOT de>
        Date: 2012-08-29 18:34
        Message: Fixed.
        Issue #TRUEZIP-288 - TrueZIP i.c.w. Java 1.7 not playing nice with Windows file shares‏

        Show
        Christian Schlichtherle added a comment - Changeset: 4d62a89c0ec3 Author: Christian Schlichtherle <christian AT schlichtherle DOT de> Date: 2012-08-29 18:34 Message: Fixed. Issue # TRUEZIP-288 - TrueZIP i.c.w. Java 1.7 not playing nice with Windows file shares‏
        Hide
        Christian Schlichtherle added a comment -

        Qui, since you have cloned the source code repository anyway, could you please quickly give the update a try? I have applied the workaround from the JSE 6 driver to the JSE 7 driver.

        Show
        Christian Schlichtherle added a comment - Qui, since you have cloned the source code repository anyway, could you please quickly give the update a try? I have applied the workaround from the JSE 6 driver to the JSE 7 driver.
        Hide
        qui.tiqe added a comment -

        I have tested the patch, and it solves the issue for me. Thank you.

        Show
        qui.tiqe added a comment - I have tested the patch, and it solves the issue for me. Thank you.

          People

          • Assignee:
            Christian Schlichtherle
            Reporter:
            qui.tiqe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: