On 25/06/2014 16:21, Daniel Fuchs wrote:
On 6/25/14 5:07 PM, Alan Bateman wrote:
Catching OverlappingFileLockException is usually a sign of a mis-use.
Can you summarize how this comes about (given the locking on "locks").
A file is just a file. So nothing prevents some other piece of code in
the same process to call FileChannel.lock() directly. For instance,
another Handler implementation might do that - given that our 'locks'
HashMap is private - it wouldn't be able to use it.
Okay, so this concern isn'tFileHandler but rather malicious or misguided
usages in other code running in the same VM. In that case I think the
comment could be a bit clearer that it's something other than the
FileHandler that is locking the file.
The issue here is that CREATE + WRITE + APPEND will probably succeed
if the file exists - even though we can't write in its parent dir.
I am not sure we should be concerned about the performance of
opening the file for the FileHandler. It's usually not something
you do very often.
I don't think the Files.isXXX is useful here, especially if there are
other things changing the file system at the same time. There is no
guarantee that FileChannel.open will succeed. This may be a case where
you have to catch the IOException and continue (it's not nice to use
exceptions for control-flow but this may be one of these cases where it
becomes necessary.
-Alan.
