On Mon, Jun 3, 2013 at 4:29 PM, sebb <seb...@gmail.com> wrote: > On 3 June 2013 21:05, Gary Gregory <garydgreg...@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. >
A right, I should have mentioned in my previous message that we should/could relax that. I'm not attached to a particular option here, just interesting to discuss. I'm happy to go with whatever working solution you have. Gary > 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 <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 > > --------------------------------------------------------------------- > 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
