Date: Thu, 23 Aug 2001 11:54:46 -0700
From: Graham Hamilton <###@###.###>
To: Mark Reinhold <###@###.###>, ###@###.###
Subject: state checks in FileChannel.tryLock()
I've run into a recent change in behavior in FileChannel.tryLock() that
is impacting my file locking code in the logging FileHandler class.
The change is that the FileChannelImpl.tryLock code now checks that
the target channel is both readable and writeable. This is a fix for
4486154, where we get lower-level IO failures if we try and lock a
file without having a writeable channel.
Now, if this is really the intended and necessary semantic, I can fix
FileHandler to work with it.
However, I am concerned that it is a non-obvious semantic. In general,
it seems reasonable to require that someone have write access to a
channel they are trying to lock, but it is much less obvious that
they should require read access. I suspect a lot of developers are
going to type in the same kind of simple file locking code that I wrote,
and be surprised that it doesn't work:
FileOutputStream lockStream = new FileOutputStream(fname);
FileChannel fc = lockStream.getChannel();
FileLock fl = fc.tryLock();
So I would suggest that (if possible) we change the access checks to
only require write access to the channel and not to require read access.
Here is a small example test case and the resulting exception.
import java.io.*;
import java.nio.*;
import java.nio.channels.*;
public class Test {
public static void main(String argv[]) {
try {
String fname = "foo.lck";
FileOutputStream lockStream = new FileOutputStream(fname);
FileChannel fc = lockStream.getChannel();
FileLock fl = fc.tryLock();
if (fl == null) {
// We failed to get the lock.
throw new Error("no lock");
}
} catch (Throwable th) {
System.err.println("caught : " + th);
th.printStackTrace();
}
}
}
caught : java.nio.channels.NonReadableChannelException
java.nio.channels.NonReadableChannelException
at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:496)
at java.nio.channels.FileChannel.tryLock(FileChannel.java:871)
at Test.main(Test.java:20)
From: Graham Hamilton <###@###.###>
To: Mark Reinhold <###@###.###>, ###@###.###
Subject: state checks in FileChannel.tryLock()
I've run into a recent change in behavior in FileChannel.tryLock() that
is impacting my file locking code in the logging FileHandler class.
The change is that the FileChannelImpl.tryLock code now checks that
the target channel is both readable and writeable. This is a fix for
4486154, where we get lower-level IO failures if we try and lock a
file without having a writeable channel.
Now, if this is really the intended and necessary semantic, I can fix
FileHandler to work with it.
However, I am concerned that it is a non-obvious semantic. In general,
it seems reasonable to require that someone have write access to a
channel they are trying to lock, but it is much less obvious that
they should require read access. I suspect a lot of developers are
going to type in the same kind of simple file locking code that I wrote,
and be surprised that it doesn't work:
FileOutputStream lockStream = new FileOutputStream(fname);
FileChannel fc = lockStream.getChannel();
FileLock fl = fc.tryLock();
So I would suggest that (if possible) we change the access checks to
only require write access to the channel and not to require read access.
Here is a small example test case and the resulting exception.
import java.io.*;
import java.nio.*;
import java.nio.channels.*;
public class Test {
public static void main(String argv[]) {
try {
String fname = "foo.lck";
FileOutputStream lockStream = new FileOutputStream(fname);
FileChannel fc = lockStream.getChannel();
FileLock fl = fc.tryLock();
if (fl == null) {
// We failed to get the lock.
throw new Error("no lock");
}
} catch (Throwable th) {
System.err.println("caught : " + th);
th.printStackTrace();
}
}
}
caught : java.nio.channels.NonReadableChannelException
java.nio.channels.NonReadableChannelException
at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:496)
at java.nio.channels.FileChannel.tryLock(FileChannel.java:871)
at Test.main(Test.java:20)
- relates to
-
JDK-4486154 (fs) FileChannel.lock/tryLock throw IOException when not open for read & write
-
- Closed
-