Hi Remi,
On 04/15/11 11:05, Rémi Forax wrote:
Hi Mandy,
if fc.close() throws an IOException , it goes wrong.
I think you need to put fc.close() in its own a try/catch(IOException).
That's a good point. I think it should throw IOException if anything
goes wrong with fc.close(). Revised the fix:
http://cr.openjdk.java.net/~mchung/jdk7/7032589/webrev.01/
The existing implementation looks a bit suspicious as it silently
ignores the IOException thrown by tryLock() and uses that lock file. I
am inclined to leave the existing behavior as it is to minimize
behavioral change. And just resolve this file descriptor leak issue in
this fix. I'll open a bug to follow up this.
412 try {
413 FileLock fl = fc.tryLock();
414 if (fl == null) {
415 // We failed to get the lock. Try next file.
416 continue;
417 }
418 // We got the lock OK.
419 } catch (IOException ix) {
420 // We got an IOException while trying to get the lock.
421 // This normally indicates that locking is not
supported
422 // on the target directory. We have to proceed without
423 // getting a lock. Drop through.
424 }
Mandy
