Apparent bug in FileLock

Discussion in 'Java' started by Harold Yarmouth, Nov 19, 2008.

  1. 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, Nov 19, 2008
    #1
    1. Advertising

  2. 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).
     
    Harold Yarmouth, Nov 20, 2008
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. David Zimmerman

    confused abt FileLock behavior

    David Zimmerman, Jul 28, 2003, in forum: Java
    Replies:
    3
    Views:
    447
  2. Replies:
    0
    Views:
    5,229
  3. Replies:
    4
    Views:
    8,475
    toddwh50
    Mar 11, 2010
  4. alejandrina

    Problem with FileLock

    alejandrina, Jul 13, 2007, in forum: Java
    Replies:
    12
    Views:
    633
    alejandrina
    Jul 30, 2007
  5. Josef 'Jupp' SCHUGT

    epoch/2 bug in filelock.rb?

    Josef 'Jupp' SCHUGT, Jan 11, 2004, in forum: Ruby
    Replies:
    1
    Views:
    129
    Josef 'Jupp' SCHUGT
    Jan 14, 2004
Loading...

Share This Page