[
https://issues.apache.org/jira/browse/IO-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673459#comment-13673459
]
Sebb commented on IO-385:
-------------------------
The IAE occurs when the input file position is greater than the input file
size. Thus the bytes remaining are negative.
It's possibly a bug in FileChannelImpl that it passes a negative number to its
map() method.
It would certainly be more helpful if the exception was more specific.
truncate() resets the file positon so that it is no greater than the size,
however this only applies to the current channel.
Other channels pointing to the same file are not updated so can have a position
which is inconsistent with the file size.
AFAICT it's not possible to avoid the problem, so it's probably best to just
document it.
> 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
