RandomAccessFile raf = new RandomAccessFile(file, "rw");
FileLock fileLock = raf.getChannel().lock();
Reader reader = new FileReader(file);
int ch = reader.read();

causes

java.io.IOException: The process cannot access the file because another 
process has locked a portion of the file



That is incorrect. It is the same process, not another process, that has 
locked a portion of the file.

 From FileLock's Javadoc:

File locks are held on behalf of the entire Java virtual machine. They 
are not suitable for controlling access to a file by multiple threads 
within the same virtual machine.


This strongly implies that the IOException is in error: the JVM holding 
a file lock should not inhibit the same JVM from opening the same file 
in another manner.


This situation has arisen from an effort to get an exclusive lock on a 
file before reading it, then overwriting it after doing some computations.

It won't let me get an exclusive lock using just a FileInputStream. Nor 
can I apparently obtain a Reader wrapping a RandomAccessFile. But I want 
Reader's string-handling and character-encoding functionality.

Ergo, using a RandomAccessFile to get the exclusive lock during the 
operation, and a Reader to do the actual reading.

How do I make this work? The requirements:

* Have the JVM hold an exclusive lock on the file from the start of the 
read operation until the end of the subsequent write.
* Have the read part of the operation performed via Reader.
* It would be nice if I could use Writer rather than RandomAccessFile 
for the write part.

In fact, it would be nice if I could lock the file as seen by the other 
processes without associating the lock with ANY streams in the JVM. Then 
I could lock, read file, write to a temp file, rename-swap the files 
(using yet another temp file), and then delete the temp file, then 
relinquish the lock, and the file's modification and replacement will 
appear atomic to other processes. This one would have the salutary 
benefit that the previous version is preserved in case of error, and at 
no time can a power interruption or other sort of lossage destroy both 
the old and new version of the file.

Harold Yarmouth wrote:
> RandomAccessFile raf = new RandomAccessFile(file, "rw");
> FileLock fileLock = raf.getChannel().lock();
> Reader reader = new FileReader(file);
> int ch = reader.read();
> 
> causes
> 
> java.io.IOException: The process cannot access the file because another 
> process has locked a portion of the file
> 
> That is incorrect. It is the same process, not another process, that has 
> locked a portion of the file.
> 
>  From FileLock's Javadoc:
> 
> File locks are held on behalf of the entire Java virtual machine. They 
> are not suitable for controlling access to a file by multiple threads 
> within the same virtual machine.
> 
> 
> This strongly implies that the IOException is in error: the JVM holding 
> a file lock should not inhibit the same JVM from opening the same file 
> in another manner.

I've done some Googling and there is one other report of this behavior, 
which seems to concur that it's buggy. It's at 
http://www.velocityreviews.com/forums/t142841-filelock-and-fileinputstreamfileoutputstream.html 
and does not suggest a workaround.

I can't seem to find any workaround save to not use FileLock at all, or 
only use shared locks (and therefore not use FileLock at all on some 
platforms -- every lock would have to be requested shared, tested for 
actually coming out exclusive, and discarded if so).

What a pain. I think I may just get rid of using file locks and pray no 
other process scribbles on the file while my application is making 
changes, or relies on it being in a consistent state.

It looks like Java still has no really good way to manage file locking 
in a way that supports making complex file manipulations appear atomic 
to other processes, while also supporting implementing them arbitrarily 
within the one JVM (if necessary, using ordinary synchronized, wait, and 
notify on a suitably-chosen object to make them appear atomic to other 
threads within the JVM).