You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2014/01/04 16:23:35 UTC
unpredictable failure of FileChannel#transferFrom
Hi all,
in ResourceUtils#copy we'll use FileChannel#transferFrom if source and
target are Files and we don't need to modify the contents. It looks as
if transferFrom uses mmap under the covers and sometimes fails to do so
- for example when one file is on a network file system[1] but it looks
as if this was not the only issue[2].
>From the stacktraces in [1] it looks as if all Ant sees is a plain
IOException so we cannot handle the case by falling back to stream based
copying.
One option could be yet another flag to the copy methods together with
an attribute on all tasks that happen to use it - this would give user
maximal control. Another option may be a system property that users
could set to disable transferFrom in the rare cases where it is causing
problems - which would increase the documentation burden and isn't too
IDE friendly. Other choices?
Stefan
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=54397
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=53102
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: unpredictable failure of FileChannel#transferFrom
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 4 janv. 2014 à 16:23, Stefan Bodewig <bo...@apache.org> a écrit :
> Hi all,
>
> in ResourceUtils#copy we'll use FileChannel#transferFrom if source and
> target are Files and we don't need to modify the contents. It looks as
> if transferFrom uses mmap under the covers and sometimes fails to do so
> - for example when one file is on a network file system[1] but it looks
> as if this was not the only issue[2].
>
> From the stacktraces in [1] it looks as if all Ant sees is a plain
> IOException so we cannot handle the case by falling back to stream based
> copying.
>
> One option could be yet another flag to the copy methods together with
> an attribute on all tasks that happen to use it - this would give user
> maximal control. Another option may be a system property that users
> could set to disable transferFrom in the rare cases where it is causing
> problems - which would increase the documentation burden and isn't too
> IDE friendly. Other choices?
Option 1 seems the best but a lot of work. If I would do it myself, I would go with option 2, together with an new Ant task which allow to set a system property from a build file, to be more IDE friendly.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: unpredictable failure of FileChannel#transferFrom
Posted by Stefan Bodewig <bo...@apache.org>.
On 2014-01-06, Jesse Glick wrote:
> On Sat, Jan 4, 2014 at 10:23 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> all Ant sees is a plain IOException so we cannot handle the case by
>> falling back to stream based copying.
> Why not? Even if the IOException is “genuine” (missing permissions,
> etc.), a fallback to stream copying would presumably fail with the
> same error.
Probably. Maybe I'm too concerned about wasted time trying the same
copy operation twice.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: unpredictable failure of FileChannel#transferFrom
Posted by Jesse Glick <ty...@gmail.com>.
On Sat, Jan 4, 2014 at 10:23 AM, Stefan Bodewig <bo...@apache.org> wrote:
> all Ant sees is a plain IOException so we cannot handle the case by falling back to stream based copying.
Why not? Even if the IOException is “genuine” (missing permissions,
etc.), a fallback to stream copying would presumably fail with the
same error.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org