Odd File-locking problem

[Rhino]

I have a Java project that runs just fine in Eclipse 3.5.1 using the "Run as
Java application" option. However, when I execute the same program via an
Ant script, I get a java.io.IOException. The error message says "Couldn't
get lock for [the name I specified for my log file]. Looking at the Java
code, the problem exists in FileHandler.class, specifically in this
constructor:
public FileHandler(String pattern, int limit, int count, boolean append)

This is the code that is crashing:

int unique = -1;

for (; {

unique++;

if (unique > MAX_LOCKS) {

throw new IOException("Couldn't get lock for " + pattern);

}

It appears that I am exceeding MAX_LOCKS but I'm not sure what value
MAX_LOCKS has, why I'd be exceeding that value, or how to prevent it from
exceeding it.

Any idea why I'd get this behaviour in Ant but not when I run the program
with the "Run as Java application" option?

For what it's worth, I ran this program successfully via Ant many times in
previous versions of Eclipse, like 3.0.2. Have I found a bug in Eclipse
3.5.1?

 

[Roedy Green]

The error message says "Couldn't
get lock for [the name I specified for my log file]. Looking at the Java
code, the problem exists in FileHandler.class, specifically in this
constructor:

Sounds like ANT is trying to reserve the log file twice. Is there
anything else that could be using the log file? like your app for
example?
--
Roedy Green Canadian Mind Products
http://mindprod.com

When a newbie asks for help tracking a bug in a code snippet, the problem is usually is the code he did not post, hence the value of an SSCCE.
see http://mindprod.com/jgloss/sscce.html

 

[Rhino]

The error message says "Couldn't
get lock for [the name I specified for my log file]. Looking at the Java
code, the problem exists in FileHandler.class, specifically in this
constructor:

Sounds like ANT is trying to reserve the log file twice. Is there
anything else that could be using the log file? like your app for
example?

Since posting this question on the newsgroup, I also posted to the Eclipse
community forums and someone there is trying to help me. He has given me
this information:
-------------
...."So this means that some files are being locked and then never released
that use the given "pattern" for locking. They are released by having
the associated filehandler closed.

You didn't say if you are running this from Eclipse as an Ant launcher
or from a command line.

If you are running from a command line this means you are doing many
locks and no unlocking.

If you are running from Eclipse AND you are having run WITHIN Eclipse
instead of a separate JRE then it will be using the same JRE instance as
Eclipse is using and so if you don't unlock, even though the Ant script
has terminated, the file will stay locked because it is a static inside
the Eclipse JVM instance. So every time you run the Ant script the
number of locks would increase."
-------------

While I await his answer to the questions that I asked about this
information, I may as well get your input since I know you to be very
knowledgeable on these matters.

I am running Eclipse via the Ant launcher, i.e. it is being run within
Eclipse, not from the command line. I have tried rebooting the computer,
deleting all the visible log files (there were only 3 of them) and changing
the JRE used by Ant but still get the exact same error when I try to create
a log file with the logging FileHandler.

Is it possible that locks are somehow surviving a reboot? If yes, is there
any way that I can determine what is locked and then unlock it?

Should I be manually unlocking files when I am finished with them? If so,
how? I had always assumed that file locking was handled by the OS and/or
Java and that I didn't need to worry about locking or unlocking a given
file.

Again, I am running Eclipse 3.5.1 on Windows XP.

 

[Martin Gregorie]

Is it possible that locks are somehow surviving a reboot? If yes, is
there any way that I can determine what is locked and then unlock it?

Possible, yes. Some programs prevent multiple copies of themselves from
running or prevent multiple access to a single file (such as a log file)
by creating a guard file while they're doing whatever can't be done in
parallel and then deleting it when they've finished: the presence of the
guard file is the lock.

A badly written program using this technique can quite easily leave the
guard file in place over a reboot. Finding and deleting the file will
clear the lock.