In message <[EMAIL PROTECTED]>, Marco Jacob writes: > FTPClient.retrieveFile(String, OutputStream) > >flushes the OutputStream after each time it calls write(byte[], int, int)= >=2E ... >I think, FTPClient.retrieveFile(String, OutputStream) should never flush >or close() the given OutputStream. The calling method should do this. > >However, can this be changed in the next release?
There are three separate issues here. The first two concern the flush issue and the third the close issue. 1. retrieveFile calls Util.copyStream as a convenience. So it's not retrieveFile that is doing the flushing. It's a byproduct of the call. Should retrieveFile call Util.copyStream? Probably, because otherwise we'd just have to write another stream copying utility function. 2. Util.copyStream flushes the output stream after every write. Does it have to do this? It doesn't have to do this for retrieveFile, but it does have to do it to support interactive sessions for other protocols like telnet which would hang because java.io classes would hold onto their buffers. At the very least, it's a holdover from JDK 1.1 days when the call to flush was the only way to make some things work. Since not every caller of copyStream needs the flushing, an option can be provided to disable it. We can leave flushing as the default to avoid breaking anything and add a new method with an extra argument turning flushing on or off (the original method would call it with flushing on). FTPClient can then use this method with flushing turned off. However, the underlying OutputStream may wind up making its own flush calls inside of write, so this may not completely resolve your particular situation. 3. Should retrieveFile close the output stream? No. In fact, it does not. Only the source is closed, which has to be done anyway because the end of stream is reached. Historical note. I didn't want there to be a retrieveFile or a storeFile method because I thought convenience methods should go into subclasses or wrappers. retrieveFileStream and storeFileStream already provided the required primitive functionality. But users really wanted retrieveFile and storeFile in FTPClient, so there you go. Anyway, if you think the solution in 2. is useful, we can make the appropriate adjustments. However, I have dim memory that there may be an issue with not flushing in storeFile. We can put in flush before the close there just in case. I think some java.io classes in JDK 1.1 days may not have flushed buffered output on closing and there may have been incomplete data written. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
