8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed

[Brian Burkhalter]

On Dec 2, 2014, at 12:59 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> I think it would be better to fix the underlying issue, which is that FIS/FOS/RAF will create a FileChannel that is open after the file has been closed.

Agreed.

> Try the patch below as a starting point. This will create the FileChannel and close it before the reference is handed out. A cleaner solution would be to create the FileChannel in the closed state but it would involve more intrusive changes.
> 
> -Alan
> 
> diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java
> --- a/src/java.base/share/classes/java/io/FileInputStream.java
> +++ b/src/java.base/share/classes/java/io/FileInputStream.java
> @@ -367,6 +367,13 @@
>          synchronized (this) {
>              if (channel == null) {
>                  channel = FileChannelImpl.open(fd, path, true, false, this);
> +                if (closed) {
> +                    try {
> +                        channel.close();
> +                    } catch (IOException ioe) {
> +                        throw new InternalError(ioe); // should not happen
> +                    }
> +                }
>              }

It looks like it’s possible that ‘closed’ could be ‘false’ when tested in the if-statement but become ’true’ before the return if close() were called on another thread in the minuscule intervening time. Should perhaps the closeLock be used to prevent that?

>              return channel;

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141202/97411cf9/attachment-0001.html>