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 somewhere. Gary On Mon, Jun 3, 2013 at 4:00 PM, sebb <seb...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
