On 6/23/14 4:53 PM, Alan Bateman wrote:
On 23/06/2014 10:48, Daniel Fuchs wrote:
:
All in all - I feel our best options would be to revert to using
CREATE, or use CREATE_NEW + DELETE_ON_CLOSE, or not do anything
and live with the issue.
Hopefully some nio experts will chime in ;-)
The logging use of FileLock is a bit unusual but looking at it now then
I don't see the reason why it needs to use CREATE_NEW.
OK - thanks - in the discussion that ended up in the patch where
CREATE_NEW was introduced Jason (I think it was Jason) pointed at
https://bugs.openjdk.java.net/browse/JDK-4420020
I'm guessing here that maybe it would be wrong to use an already
existing lock file if you don't have the rights to write to
its directory - and that using CREATE_NEW ensures that you have
all necessary access rights all along the path.
I don't think
DELETE_ON_CLOSE is suitable here as that work is for transient work
files which isn't the case here. Instead it could use deleteOnExit to
have some chance of removing it on a graceful exit.
Right - I suggested a patch in another mail where I just use that.
BTW: Do you know why locks is Map? Would a Set do?
It certainly looks as if we could use a simple HashSet here.
Thanks Alan!
-- daniel
-Alan.
