tryLock gets a lock when it shouldn't

[Rob MacKay]

Hello,

I have a routine in my application that tests to see if a given file is locked. This file belongs to another java application written by someone else in my organization and I have no idea if they are doing anything to correctly lock the file. However, on windows, when the other application is running, I am prevented from deleting the file using windows explorer. Given that bit of logic, one would assume that my tryLock method call should not be returning me an exclusive lock, which it in fact does.

Any idea why I would be able to get an exclusive lock on a file that, from the outside, appears to already be locked by the other running application?

Note - the other application is running in a completely separate VM.

Have I provided enough information? The method for getting the lock is quite standard that you see on most every other file lock question.

[Greg Charles]

Well, you probably should say that you're talking about the tryLock() method in java.nio.channels.FileChannel, if I even guessed right. I've never needed it myself, but as far as I can tell, it should return null if some other process has an exclusive lock on the file. I suppose you could test that by writing two Java programs that try to lock the same file. I wouldn't take Windows' not being able to delete a file as proof there was an exclusive lock on it though. What if something had the file opened in read only mode? Wouldn't that be a non-exclusive lock and yet still prevent it from being deleted? If the file is a folder, maybe a lock on one of its children would prevent it from being deleted. Maybe Windows is just having a bad day. It certainly seems to prevent me from deleting files that I know no process is touching.

[Rob MacKay]

Greg Charles wrote:Maybe Windows is just having a bad day. It certainly seems to prevent me from deleting files that I know no process is touching.

Agreed. I can't say that haven't had that happen before.

I think I narrowed it down a bit though and it seems that I can detect locks on the executable itself (which I wasn't checking before), just not the jar files it may have loaded, which is what Windows wouldn't let me touch. The problem is that I want to modify / replace that jar file and wanted to be able to detect the scenario where it was in use.