RFR: 8048020 - Regression on java.util.logging.FileHandler (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Fri Jul 4 16:35:09 UTC 2014

On 01/07/2014 10:25, Daniel Fuchs wrote:

Hi Jason, Alan, Here is an updated version of the fix that does a bounded retry (retries once - and if it fails, proceeds with the next name). I have also added NOFOLLOWLINKS - for the case where we try to open an existing Lockfile, and suppressed the Files.isWritable check since that will be taken care of by the call to FileChannel.open. http://cr.openjdk.java.net/~dfuchs/webrev8048020/webrev.01/ I also updated the comments to make it clear that the file could not have been locked by another instance of FileHandler (since that would have been taken care of by our global 'locks' synchronization). best regards, -- daniel This looks okay to me except for the zombie file case. I think I missed the reason for using APPEND. Also you catch FileNotFoundException (which is not thrown by FileChannel.open) so I wonder if you mean to catch IOException so that you handle all possible I/O exceptions. If you meant IOException to handle any error then the isWritable on the parent directory isn't needed (we can make the isRegularFile check go away too if you want).

In the test case then the the use of getAbsolutePath seems redundant. Also just to mention that setup method could use Files.createTempDirectory.

-Alan

More information about the core-libs-dev mailing list