commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [IO] FileUtils.doCopyFile - should behaviour be changed?
Date Mon, 03 Jun 2013 20:29:48 GMT
On 3 June 2013 21:05, Gary Gregory <garydgregory@gmail.com> wrote:
> 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.

In which case if the input file has grown in the meantime, the method
will fail, because the final sizes are checked.
However if the input file has been truncated (assuming this does not
trigger IAE or the infinite loop), the method may not fail, as it only
checks the final sizes.
This is inconsistent.

The current code is only well-behaved for static files.

> Then
> there is the infinite loop issue I saw mentioned.

Yes, I think I have a fix for that.

> 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
> somewhere.

Well, I raised IO-384 for that.
But now I just don't see the use-case for picking the file size at an
arbitrary point in time.

> Gary
>
>
> On Mon, Jun 3, 2013 at 4:00 PM, sebb <sebbaz@gmail.com> 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.
>>
>> WDYT?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message