This content has been marked as final. Show 5 replies
See the Javadoc. In general file locks are only specified to protect against other file locks. The behaviour you describe is permitted by the wording. Some platforms, ie Windows, go further, but that's because of the platform, not because of Java.
Is it like windows has implemented locking and Apple has not implemented ?
Actually I tried using 2 threads.
Thread 1 opens the file, writes in the file, continously flushes into the file and second thread tries to delete the file.
In this scenario also I am expecting an exception but I am not getting in Apple but works fine in Windows.
What might be the issue?
Edited by: 851636 on Apr 12, 2011 3:16 AM
The platforms have different behaviours, due to some stupid decisions made in Unix ('advisory file locking') in about 1983 by people who I am sorry to say didn't know what they were talking about. I told them at the time ;-(1 person found this helpful
In the upshot, Java has no choice but to implement the lowest common denominator behaviour, ie lock does not lock against delete or even read :-(((((((
All you can do about it is not rely on any behaviour that isn't specified.
So is there any way to test my API on Apple mac? I don't want to use mock objects.
I've answered that. If your API relies on the Windows behaviour, which is not specified in the Javadoc for FileLock, it will fail on the Mac, and Unix, and Linux, and AIX for all I know, and HP/UX, and Solaris, and ...
You can't test something that cannot work.