we need the ability to open a file for exclusive
             access. we need this to prevent file corruption in
             our database product. such a file once opened would
             not be openable by any other process until closed.
             the suggested implementation is that the open method
             of RandomAccessFile accept an additional mode character
             which indicates that exclusive access is desired. Mode
             strings currently support "r" and "rw". please add
             'e' to mean exclusive access. the addition of e to
             the mode string causes the file to be opened in a
             non-sharable mode, preventing any other process from
             opening the file. if the file is already opened, then
             access is denied and an exception is thrown. on systems
             which cannot support exclusive access, the runtime should
             support it instead, by using some form of lock file. this
             shouldn't be a problem, because most operating systems
             support this feature.

              xxxxx@xxxxx   Together Software Inc.

======================================================================

[another user   xxxxx@xxxxx  1997-12-08]

While working on a project to develop a suite of
Java software that accesses a human-readable text
database, my team and I did not find any
way of enforcing file locking in Java.

We used native code as a workaround, but it was a
sloppy approach.

Are there any plans to introduce file locking
into the IO class libraries? It seems to me that
this is a fairly important feature.

try to implement a dang fool lock file
======================================================================

Full support for file locking/unlocking must wait for a feature release after
JDK 1.2.  We may, however, be able to include a simple atomic-file-create method
in this release (RFE 4130498).  --  xxxxx@xxxxx  4/19/1998


There is no easy solution to this problem because the native file-locking
mechanisms on Windows and Unix are vastly different in nature.

In Windows, file locking is mandatory: If one process locks a file (or part of
a file) and an xxxxx  process tries to access the file in a way that would
violate the lock then the kernel causes the file operation to fail.

In Unix, file locking is advisory: When a process locks a file the kernel does
nothing to prevent an xxxxx  process from accessing the file -- it's up to the
processes to cooperate and check the lock before accessing the file.  (This is
not completely true -- with most Unix kernels you can get mandatory locking by
setting a file's mode bits in just the right way -- but it is the usual
practice with Unix operating systems.)

As far as we can see, given a mandatory locking mechanism there's no way to
emulate an advisory mechanism, and given an advisory mechanism there's no
efficient way to emulate a mandatory mechanism.  This is important because in
the Java platform it's essential to ensure that APIs work consistently across
operating systems.  Adding a file-locking API that is mandatory on Windows and
advisory on Unix would not be consistent with this goal.

Having done this analysis, we're currently looking into how to implement a
simple advisory file-locking scheme on Windows.  This would not interact at all
with the native Windows locking mechanism, but it would make it easy for Java
programs on Windows to lock files against each  xxxxx  and possible for  xxxxx 
programs to use these locks so long as they observe the same conventions, which
would be documented in the release notes.  If we can work this scheme out then
we'll consider adding a small whole-file locking API in the upcoming Merlin
release (1.4) of J2SE.  On the Unix side this API would simply map to the
native fcntl(2) advisory-lock function.

--  xxxxx@xxxxx  2001/2/22


After evaluating all of the available options, the JSR-51 (NIO) expert group
decided upon a design that does not attempt to hide the difference between
mandatory and advisory file locks.  As of the J2SE 1.4 beta release, the
FileChannel class has a set of lock methods, and these methods return an
instance of FileLock to represent the lock.

--  xxxxx@xxxxx  2001/7/16

We created a LockFile class that created and locked
a given file using native C methods. Problem is, everyone has to remember
to use this interface.

After JDK 1.2? It is not a cosmetic extra,
it is very important. Most OS have file locking,
or they wouldn't work, so what's so hard about
doing it? Has it even been tried yet?

you've got to be kidding! there's no support for
exclusive write access to a file until after
jdk 1.2!!

I need something similar but in my case I need to support multiple concurrent
reader and to exclude writers while the readers are active.
the Java spec seems does not define the behavior very precisely. I guess I will
have to test different platforms, and Java VMs etc... to figure out what
policies are implemented, and implement inefficient workarounds were needed -
yuk.

No support for locking till after 1.2!? That means that easy multi-user support
goes down the drain!

This is a truly fundamental problem - should be very
high priority.

Like everyone else who is trying to implement a database product, we need this
capability. For us, an alternative solution would be if the server program
could find out whether there were any other instances of itself running, and
refuse to start if there were. Otherwise, we will have to implement a
"dang fool lock file", too!

I was very very surprised that exclusive locking isn't 
supported in Java. This is a very serious omission that 
will require us to write native code. We feel that this 
should be a very high priority for Sun.

Unbelievable!  If someone is writing a large file and I am 
polling to see if the file has arrived, I have no way of 
knowing if the file has completed writing because Java 
cannot detect that someone else has an exclusive write 
lock.  The 'File' class should be enhanced to provide a 
canWriteExclusive() in addition to canWrite() to indicate 
this state.  This should be a high priority.

This is an urgent problem that needs to be resolved ASAP. 
Not only do we need exclusive locking semantics but we also 
need all of the standard locking semantics. This should 
include byte range locking, shared readers (which excludes 
all writers) etc.

Here we are on JDK 1.3 and this is not fixed. I don't think 
this should be a RFE, it's a *BUG*. I had tool a look on 
the sources of the JVM 1.3. it will be so easy for Sun to 
do this (the function are written but not interfaced with 
Java side) ! 

I have tried to write a natice an java classes to use 
_sopen instead of open. (soon [10/2000] on www.denty.org)

Should be very high priority for Sun and only one hour of 
work to do this !

You can download a patch for this (Win32) at 
download.denty.org

For our project, we're going to try two approaches, one of 
which uses RMI, and the other of which uses CORBA.  Doesn't 
this seem a little extreme for such a seemingly simple 
concept as file-locking?

Too bad this isn't fixed yet :(.  I wrote a NT native 
method to handle it if anyone is interested.

Over 2 years later after my first comment, still no change.

Sun are soooo arrogant.

I wonder if we'll get to 1.4 and still no fix.
It wouldn't surprise me. 

Sun know NOTHING about real world apps.

While we're at it, we need range locking as well.

There's a problem with the "dang fool lock file."

That file needs to be locked as well.

It should be a bug instead of rfe. Because the "atomic-file-create
method in JDK 1.2 release (RFE 4130498)" is not atomic. Please fix this
ASAP

If we can't have explicit file locking, why not AT THE VERY 
LEAST implement a way to set a File's write permission on 
from within the API. You can turn it off (File.setReadOnly
()) but you cannot turn it back on. 

I must admit I love the passive tone of the original 
evaluation. "This would be very difficult because...." I'd 
like them to try to tell my Boss that same line and keep 
their job.

My Java apps MUST see the locks put by other Windows apps.
Merlin will not help me ? !!!!

To emulate advisory whole file locking with the Windows 
API, just lock a region (far) beyond the end of the file. 
For Windows 9x lock the byte at 2^32 - 1, for Windows 
NT/2000 lock the byte at 2^64 - 1. While this may not be 
perfect (it fails for files at the limit), in practice it 
is likely to be adequate.
To implement mandatory locking range locking, add a new 
class of RandomAccessFile which allows at most a single 
range to be locked (at any one time). Any attempt to write 
without a lock or outside of the locked region can be 
easily blocked without a system call (all it takes is a 
couple of comparisons). It doesn't matter if the underlying 
system lock semantics are mandatory or not. It wouldn't be 
hard to extend this to multiple lock regions. This is more 
restrictive than the usual system API only in that you MUST 
acquire a lock before writing to this type of file. I don't 
see this as a serious problem. If you must attempt to write 
to the file without having a lock, then just create an 
ordinary RandomAccessFile on the same handle (which then 
won't be checked).

WORKAROUND
Why not use a locking file, something like:

public boolean lock() {
try {
    File lock = new File(...); //Lock file
    if(lock.createNewFile()) {
        lock.deleteFileOnExit();
        return true;
    }
} catch(IOException ignore) {}
return false;
}

The code above works since JDK 1.2, if you are using an 
earlier
vesrion, you could use File.mkdir() instead of 
File.createNewFile()

That is not a perfect approach, beacuse an unaware proccess
might still break your locking semantics, but for most of
the cases it works.

Sorry, it works for *all* the cases, I should have said, 
that for most cases is enough.

Please don't assume the lowest common denominator (advisory 
locking)!  If the problem is deciding whether to do 
mandatory or advisory locking, why not do both?  It would 
seem that, for apps which need exclusivity, mandatory 
locking is always the better (and stronger) choice.  
However, compatibility with the O/S might be of greater 
important for some applications.  So, write the locking 
mechanism such that the request to lock can specify wether 
mandatory, advisory or O/S default locking is desired.  
Have a return code (or other form of query) which indicates 
which was used.  This solves the problem of what to do.  If 
doing all of the above is too much work, the initial 
implementation could just do O/S default, which should be 
easy.  Since it would be possible to determine what method 
was being used, this should be acceptable.

As the system backup application does not respect lock file 
schemes (at least for Windows), any files 'locked' in this 
way are likely to be recorded with inconsistent content. 
This is completely unacceptable.

In 1.4 beta there is a method
java.nio.channels.FileChannel.lock().
I think it does exactly what people want.

I have implemented a file locking scheme, and my biggest 
current problem is what to do with a 'power off' scenario 
which seems to happen with my trigger happy ctl-alt-del 
customers.  I created a file as suggested, but then it can 
get left around and detected by the next java program at 
startup leaving the file permanently locked.  I'm not sure 
there is a fix for that other than taking up resources that 
windows / unix force to be freed up when the JVM is gone, 
ie ports.  Aside from user intervention (which is annoying 
and shouldn't be necessary) I can't see a way around 
this ... and would hope that Sun includes the power off 
scenario in their implementation.

I've just been sent an email by some bot saying that this bug is now closed (and all the votes have been freed). But nothing has been done to fix it (it's still open and marked as in progress). WTF is going on? Suggest that everybody who  hasn't been forced to give up in disgust (I have, but hope springs eternal) and implement their own native code should come back here and reassert their vote.