commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [IO] FileUtils.doCopyFile - should behaviour be changed?
Date Mon, 03 Jun 2013 20:05:52 GMT
I'm not crazy about this one. I like the idea that the file copy is bound
by /something/, in this case the file size when the operation starts. Then
there is the infinite loop issue I saw mentioned.

What you describe feels more like a StreamUtils facitlity. I think there is
room for this functionality, but perhaps it should be in a new method


On Mon, Jun 3, 2013 at 4:00 PM, sebb <> wrote:

> The private method FileUtils.doCopyFile is used by many of the public
> FileUtils methods to do the actual file copying.
> At present this caches the input file size at the start, and only
> copies that many bytes to the output file.
> If the input file is a log file, and is growing, it will only copy the
> original size file.
> However, if the output file size is not equal to the current file size
> an exception is thrown.
> This seems unnecessarily strict - and does not agree with
> IOUtils.copy() methods which keep going until EOF.
> I think it would make more sense for FileUtils.doCopyFile to behave
> the same way, i.e. keep copying until EOF is reached.
> In which case, the file size check should be eliminated - it does not
> make sense to check the sizes if the input may to grow/shrink.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

E-Mail: |
Java Persistence with Hibernate, Second Edition<>
JUnit in Action, Second Edition <>
Spring Batch in Action <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message