Java NIO locking and NTFS network resources

Question

Hi all - just ran into a really nasty situation and I was wondering if anyone else has hit it and might have some suggestions.
Platform: JRE 1.4_02 on a Win XP machine
The following test code locks a file, then copies it to another location using NIO.
When I run it with source path on my local drives (C), it works fine. If I run it with source path on a network shared resource, it fails with an IOException with description 'Error performing inpage operation'.
If I disable the lock immediately before the copy operation, it works fine.
My conclusion is that there is something about the NIO locking implementation that prevents it from working properly with NTFS volumes on other hosts. Can this be right? I've found the following bug report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4774175
but this seems like a huge problem that would prevent folks from using NIO in many, many applications. Maybe I'm wrong on something here...
Anyway, here's the test code:
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.RandomAccessFile;
import java.nio.channels.FileChannel;
import java.nio.channels.FileLock;
* Created on May 28, 2004
* (c) 2004 Trumpet, Inc.
* @author kevin
public class test {
     private void createFile(File f) throws IOException{
          FileOutputStream os = new FileOutputStream(f);
          for(int i = 0; i < 10; i++){
               os.write(i);
          os.close();
     public test() {
          boolean testWithReleasingLockPriorToCopy = false;
          final File f1= new File("w:/temp/test2.lok");
          final File f2 = new File("w:/temp/test.lok");
          f1.delete();
          f2.delete();
          try {
               createFile(f1);
               RandomAccessFile raf1 = new RandomAccessFile(f1, "rw");
               RandomAccessFile raf2 = new RandomAccessFile(f1, "rw");
               FileChannel ch1 = raf1.getChannel();
               FileChannel ch2 = raf2.getChannel();
               FileLock flock1 = ch1.lock();
              if (!f2.getParentFile().exists() && !f2.getParentFile().mkdirs())
                   throw new IOException("Unable to create directories for destination file '" + f2 + "'");
              if (testWithReleasingLockPriorToCopy)
                   flock1.release();
               ch1.transferTo(0, raf1.length(), ch2);
               raf1.close();
               raf2.close();
          } catch (Exception e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
     public static void main(String[] args) {
          test t = new test();
}Does anyone have any pointers here? I need to be able to exclusively lock a file on a network drive (preventing any other applications from opening it), then make a copy of it. I can't use regular stream operations, because the lock prevents them from working properly (it appears that, once you grab a file lock using NIO, the only way your application can use the file is via the NIO operations - using stream operations fails...).
Thanks in advance for any help!
- Kevin

Answer 1

i've run into the same problem recently, channels working fine for local file locking, but when you turn to the network, they fail to accurately handle locks.
i ended up writing a jni utility to ship with my java application that locks files using native windows calls.
my .c file ends up looking something like this:
JNIEXPORT jint JNICALL Java_Mapper_NativeUtils_LockFile
(JNIEnv *env, jobject obj, jstring filename)
const char* ntvFilename = (*env)->GetStringUTFChars(env, filename, 0);
int retVal = (int)CreateFile
ntvFilename
, GENERIC_WRITE
, FILE_SHARE_READ
, 0
, OPEN_EXISTING
, FILE_FLAG_SEQUENTIAL_SCAN
, 0
//add code to throw java exceptions based on retVal
if (retVal == (int)INVALID_HANDLE_VALUE)
return retVal;
(*env)->ReleaseStringUTFChars(env, filename, ntvFilename);
return retVal;
JNIEXPORT jboolean JNICALL Java_Mapper_NativeUtils_UnlockFile
(JNIEnv *env, jobject obj, jint handle)
     CloseHandle((void *)handle);
return 1;
it's a little shy on the error checking side, but it provides support for network file locking that java seems to lack.