[
https://issues.apache.org/jira/browse/IO-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672733#comment-13672733
]
Sebb commented on IO-385:
-------------------------
It's almost impossible to write a test case for this, as the file cannot be
truncated whilst the transfer is in progress, and this is where the code spends
most of its time (at least with larger files).
However, it is possible to cause an infinite loop if a wait is added before the
loop starts, as this makes it easier to truncate the file in the correct place.
Equally, adding a sleep between loops shows that the file can be truncated
outside the transfer method and this can cause:
java.lang.IllegalArgumentException: Negative size
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:690)
at
sun.nio.ch.FileChannelImpl.transferFromFileChannel(FileChannelImpl.java:527)
at sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:590)
> FileUtils.doCopyFile can potentially loop for ever
> --------------------------------------------------
>
> Key: IO-385
> URL: https://issues.apache.org/jira/browse/IO-385
> Project: Commons IO
> Issue Type: New Feature
> Reporter: Sebb
>
> FileUtils.doCopyFile caches the input file size and only exits the loop once
> it has read sufficient bytes.
> If the input file is truncated after obtaining the file size, the loop might
> never exit.
> One possible way round this might be to check whether anything has been
> transferred. However, I don't know if it's possible for
> FileChannel.transferFrom() to temporarily return 0 when there is data
> available; if so that could cause some existing applications to break.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
