RFR: 8048020 - Regression on java.util.logging.FileHandler

[Alan Bateman]

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.