I inspected the code path and I think this bug has merit. Consider the
following sample application:
import org.apache.commons.io.IOUtils;
import org.apache.commons.io.output.CloseShieldOutputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
public class BrokenShield {
public static void main(String[] argv) throws IOException {
File file = File.createTempFile("broken-shield", "txt");
byte[] arbitraryData = "Hello World ".getBytes(StandardCharsets.UTF_8);
FileOutputStream fout = new FileOutputStream(file);
BufferedOutputStream bout = new BufferedOutputStream(fout, 99999);
CloseShieldOutputStream cout = new CloseShieldOutputStream(fout);
try {
// This should work because we haven't tried to close the stream
cout.write(arbitraryData);
// Here we pretend this is some stupid library that insists on
// closing a stream when it shouldn't.
cout.close();
// After we try to close the stream, new data can't be written to
// the stream. For example: cout.write(arbitraryData);
// Would throw an exception like:
// java.io.IOException: write(72) failed: stream is closed
// However, if we call flush(), no exception is thrown - this is
// inconsistent with the behavior of write()
cout.flush();
} finally {
// We properly close the stream we have to use the underlying
// stream like you would expect.
fout.close();
}
try (FileInputStream fin = new FileInputStream(file)) {
String data = IOUtils.toString(fin, StandardCharsets.UTF_8);
System.out.println(data);
}
}
}
On Thu, Aug 10, 2017 at 4:54 PM, Tomas Celaya <tomas.cel...@joyent.com> wrote:
> Would anyone mind taking a look at this issue regarding the flush method on
> ClosedOutputStream?
>
> https://issues.apache.org/jira/browse/IO-546
>
> The change is relatively trivial and the attached patch includes a test
> case. I understand the impact is significant but I think it would make
> ClosedOutputStream behave more consistently with what a user would expect.
>
> – Tomas Celaya
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
