«

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/forum...putstream.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).