8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed
Alan.Bateman at oracle.com
Thu Nov 27 08:19:01 UTC 2014
On 27/11/2014 00:35, Brian Burkhalter wrote:
> Please review at your convenience:
> Issue: https://bugs.openjdk.java.net/browse/JDK-8025619
> Patch: http://cr.openjdk.java.net/~bpb/8025619/webrev.00/
> This patch fixes the immediate problem encountered by the test included in the issue description. The fix is simply for FileKey.create() to throw an IOException directly instead of wrapping it in an Error.
> This raises the question of whether some additional verbiage in the description of getChannel() might be necessary to remind that calling close() on the source object will render the FileChannel inviable and possibly cause unforeseen subsequent exceptions.
> Also, as noted in the issue comments, it begs the question as to whether getChannel() in FileInputStream, FileOutputStream, RendomAccessFile, etc., should return null or throw an IOException if the object on which it is invoked has already been closed. If so this would need to be addressed by an issue yet to be filed and would imply a documentation change.
I don't think the fix is right, consider for example what would happen
if the file descriptor is recycled to another file before tryLock is called.
One way to fix this would be to create the FileChannel in getChannel
immediately close it (so that FileChannel doesn't leak out in the open
state). This will need a bit of work in implCloseChannel, one idea is to
have it be a no-op if !fs.valid().
More information about the nio-dev