[
https://issues.apache.org/jira/browse/IVY-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469103
]
Steve Loughran commented on IVY-401:
------------------------------------
John,
do an ant -diagnostics on your system
1. what does it say java.io.tmpdir is?
2. can ant write to that temp dir?
3. what are your TMP and TEMP env variables?
4. if you change them, does Ivy save files somewhereelse
Ignoring the error message problem, if TMP and hence java.io.tmpdir is set to
/tmp, then yes, ivy is doing the right thing by putting temp files there rather
than where the build is running.
> Ivy silently does the wrong thing when /tmp is full.
> ----------------------------------------------------
>
> Key: IVY-401
> URL: https://issues.apache.org/jira/browse/IVY-401
> Project: Ivy
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.4.1
> Environment: Linux
> Reporter: John Williams
> Priority: Minor
>
> I ran into a case where Ivy was mysteriously failing to consider revision
> 1.0.9999-local of a module called lcc.util.nlp. Inspecting the logs revealed
> that the problem was a lack of disk space:
> WARN: problem while downloading ivy file:
> /home/smcdaniel/.ivy/local/lcc/lcc.util.nlp/1.0.9999-local/ivys/ivy.xml to
> /tmp/ivy50398xml: No space left on device
> Unfortunately this warning was buried in all the output that Ivy generates!
> This suggests two possible improvements to me: fail loudly when there is an
> error saving downloaded data (as opposed to reading the data from the
> repository), and avoid using /tmp at all for ivy.xml files. (I assume a temp
> dir is used to avoid having partial ivy.xml files in the file system, but
> that's not 100% reliable on systems where /tmp is on a different physical
> volume than ~/.ivy, and it seems unnecessary to use a file at all since
> ivy.xml files are never very large.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
