Ivy
  1. Ivy
  2. IVY-1165

During retreieve: Creation of symlinks problematic in Windows with Cygwin 1.7

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0-RC2
    • Fix Version/s: 2.2.0-RC1
    • Component/s: None
    • Labels:
      None
    • Environment:

      Windows 7 64 bit
      Cygwin 1.7
      Cygwin's bin directory on PATH

      Description

      On Windows with the Cygwin 1.7 bin directory on the PATH, Ivy will create a ~1kb "symlink" file instead of copying the jar to the ivylib directory. This causes the retrieve process to fail.

      As described in IVY-353, the creation of symlinks with cygwin was problematic for Windows systems. The fix as I understand it was to attempt to create a symlink, if that failed (the expected file did not exist) then copy the jar. That worked with the default configuration of Cygwin 1.5 which attempted to create Windows link (file.lnk) files. However as of 1.7 cygwin does not default to that behavior anymore and now Ivy fails in this case.

      For either version, if cygwin's environment option "winsymlinks" is turned to off – which 1.7 defaults to – then Ivy won't successfully retrieve due to thinking that the creation of a symlink was successful.

        Activity

        Hide
        Maarten Coene added a comment -

        I've made an attempt to fix this in trunk, but I was unable to test it.
        Could you please give it a try and post your feedback here?

        thanks!
        Maarten

        Show
        Maarten Coene added a comment - I've made an attempt to fix this in trunk, but I was unable to test it. Could you please give it a try and post your feedback here? thanks! Maarten
        Hide
        John Brandy added a comment - - edited

        Thanks Maarten,

        Unfortunately, while the new check did correctly realize that a copy was needed; now the copy of the files fail during the retrieve with an exception (reopened this issue, unsure if a new issue was needed):

        java.io.FileNotFoundException: C:\work\sam\bob.jar (Access is denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:131)

        Seems the reason behind this is that cygwin creates symlinks as Windows System files. In testing this, java can not construct a FileOutputStream of a system file:

        touch tim.txt
        attrib tim.txt +s

        File tim = new File("c:/work/tim.txt");
        tim.canWrite(); // Yields True
        OutputStream out = new FileOutputStream(tim); // Yields a FNF Exception with "Access is Denied"
        

        However calling .delete() on the File does work and then allows for a FileOutputStream to be constructed as intended. In looking at the FileUtil class, it seems the check on line 122 no longer matches the comment given this odd configuration and circumstances.

        The following patch has things working in my sandbox, though java & the filesystem is not my forte enough to know if there is a more ideal solution.

        Index: src/java/org/apache/ivy/util/FileUtil.java
        ===================================================================
        --- src/java/org/apache/ivy/util/FileUtil.java	(revision 905836)
        +++ src/java/org/apache/ivy/util/FileUtil.java	(working copy)
        @@ -119,9 +119,7 @@
                         throw new IOException("impossible to copy: destination is not a file: " + dest);
                     }
                     if (overwrite) {
        -                if (!dest.canWrite()) {
        -                    dest.delete();
        -                } // if dest is writable, the copy will overwrite it without requiring a delete
        +                dest.delete();
                     } else {
                         Message.verbose(dest + " already exists, nothing done");
                         return false;
        
        Show
        John Brandy added a comment - - edited Thanks Maarten, Unfortunately, while the new check did correctly realize that a copy was needed; now the copy of the files fail during the retrieve with an exception (reopened this issue, unsure if a new issue was needed): java.io.FileNotFoundException: C:\work\sam\bob.jar (Access is denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:179) at java.io.FileOutputStream.<init>(FileOutputStream.java:131) Seems the reason behind this is that cygwin creates symlinks as Windows System files. In testing this, java can not construct a FileOutputStream of a system file: touch tim.txt attrib tim.txt +s File tim = new File( "c:/work/tim.txt" ); tim.canWrite(); // Yields True OutputStream out = new FileOutputStream(tim); // Yields a FNF Exception with "Access is Denied" However calling .delete() on the File does work and then allows for a FileOutputStream to be constructed as intended. In looking at the FileUtil class, it seems the check on line 122 no longer matches the comment given this odd configuration and circumstances. The following patch has things working in my sandbox, though java & the filesystem is not my forte enough to know if there is a more ideal solution. Index: src/java/org/apache/ivy/util/FileUtil.java =================================================================== --- src/java/org/apache/ivy/util/FileUtil.java (revision 905836) +++ src/java/org/apache/ivy/util/FileUtil.java (working copy) @@ -119,9 +119,7 @@ throw new IOException( "impossible to copy: destination is not a file: " + dest); } if (overwrite) { - if (!dest.canWrite()) { - dest.delete(); - } // if dest is writable, the copy will overwrite it without requiring a delete + dest.delete(); } else { Message.verbose(dest + " already exists, nothing done" ); return false ;
        Hide
        Maarten Coene added a comment -

        I've tried another approach and committed it to svn trunk, could you please give it a try?
        The reason is that I want to avoid changing the existing FileUtils.copy-code because it could give unexpected side-effects, so it seemed better to me if that code could be left untouched...

        thanks,
        Maarten

        Show
        Maarten Coene added a comment - I've tried another approach and committed it to svn trunk, could you please give it a try? The reason is that I want to avoid changing the existing FileUtils.copy-code because it could give unexpected side-effects, so it seemed better to me if that code could be left untouched... thanks, Maarten
        Hide
        John Brandy added a comment -

        Tested the latest change Maarten and everything works!

        Thanks!

        Show
        John Brandy added a comment - Tested the latest change Maarten and everything works! Thanks!

          People

          • Assignee:
            Maarten Coene
            Reporter:
            John Brandy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development