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

[Brian Burkhalter]

On Nov 27, 2014, at 12:19 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 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.

Perhaps we are at cross-purposes here. The supplied patch was intended to address only the specific failure exposed by the test in the issue description. The last two paragraphs of the review request were in effect asking whether this issue should be constrained to this specific test error and a second issue filed for the more general case, or whether this issue should be used to cover both.

Brian

> 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().

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