[
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.
