RFR: 8048020 - Regression on java.util.logging.FileHandler
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 NO_FOLLOW_LINKS - 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/webrev_8048020/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