|
Quick Lists
|
|
Bug ID:
|
6822643
|
|
Votes
|
0
|
|
Synopsis
|
(fc) AsynchronousFileChannel.close does not invalidate FileLocks
|
|
Category
|
java:classes_nio
|
|
Reported Against
|
|
|
Release Fixed
|
7(b57)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
|
|
Submit Date
|
26-MAR-2009
|
|
Description
|
AsynchronousFileChannel#close does not release and invalidate the valid FileLocks that were obtained from the channel. This is demonstrated with this simple test case:
impor java.nio.file.*;
import static java.nio.file.StandardOpenOption.*;
import java.nio.channels.*;
public class Test {
public static void main(String[] args) throws Exception {
Path file = Paths.get(args[0]);
AsynchronousFileChannel ch = AsynchronousFileChannel.open(file, READ, WRITE);
FileLock lock = ch.lock().get();
ch.close();
if (lock.isValid())
throw new RuntimeException("Lock is still valid?");
}
}
The bug is that SharedLockTable.removeAll is using lock.channel() rather than lock.acquiredBy() when checking the owner of the file lock.
Posted Date : 2009-03-26 15:40:00.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
See description.
Posted Date : 2009-03-26 15:40:00.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |