ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Brandy (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (IVY-1165) During retreieve: Creation of symlinks problematic in Windows with Cygwin 1.7
Date Wed, 03 Feb 2010 01:09:18 GMT

    [ https://issues.apache.org/jira/browse/IVY-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828875#action_12828875
] 

John Brandy edited comment on IVY-1165 at 2/3/10 1:08 AM:
----------------------------------------------------------

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):
{quote}
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)
{quote}


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:

{quote}
touch tim.txt
attrib tim.txt +s
{quote}

{code}
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"
{code}

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.

{code}
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;
{code}


      was (Author: jbran):
    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:
{quote}
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)
{quote}


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:

{quote}
touch tim.txt
attrib tim.txt +s
{quote}

{code}
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"
{code}

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.

{code}
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;
{code}

  
> During retreieve: Creation of symlinks problematic in Windows with Cygwin 1.7
> -----------------------------------------------------------------------------
>
>                 Key: IVY-1165
>                 URL: https://issues.apache.org/jira/browse/IVY-1165
>             Project: Ivy
>          Issue Type: Bug
>    Affects Versions: 2.1.0-RC2
>         Environment: Windows 7 64 bit
> Cygwin 1.7
> Cygwin's bin directory on PATH
>            Reporter: John Brandy
>            Assignee: Maarten Coene
>             Fix For: trunk
>
>
> 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|http://issues.apache.org/jira/browse/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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message