JDK-8252883 : AccessDeniedException caused by delayed file deletion on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 8u121,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-07
  • Updated: 2021-05-25
  • Resolved: 2021-02-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15 JDK 16 JDK 17 JDK 8 Other
11.0.12-oracleFixed 13.0.8Fixed 15.0.4Fixed 16.0.1Fixed 17 b12Fixed 8u301Fixed openjdk8u302Fixed
Description
Customer has been experiencing java.nio.file.AccessDeniedException in Windows family platforms intermittently. The exception is not thrown by an illegal access to the file, but its lock file. The file permission is correctly set.  
From their analysis, the exception could be caused by the file deletion mechanism of Windows OS. The basic steps are illustrated below:

 1. A Java process submit a request to delete a lock file
 2. The control is returned from the method but the actual deletion is
 delayed by Windows.
 3. Before the lock file is actually removed, another Java process tries to create a file of same name which throws an AccessDeniedException.

Stack Trace(8u121): 
 java.nio.file.AccessDeniedException: xxx.log.lck
       at
 sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
       at
 sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
       at
 sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
       at
 sun.nio.fs.WindowsFileSystemProvider.newFileChannel(WindowsFileSystemProvider.
 java:115)
       at java.nio.channels.FileChannel.open(FileChannel.java:287)
       at java.nio.channels.FileChannel.open(FileChannel.java:335)
       at java.util.logging.FileHandler.openFiles(FileHandler.java:459)
       at java.util.logging.FileHandler.<init>(FileHandler.java:402)

Customer's request is how they should work around such a situation.
 e.g.
   Should deal with the exception in try-cath block in application code
   Should deal with the exception in the internal JDK's implementation
   Others
Comments
Fix request (15u): and to 15u, too. About the same testing run results and no disputable changes.
25-05-2021

Fix request (13u): I'd like to backport it to 13u, too. Applies clean with only a copyright year difference. Full night run completed without visible issues.
17-05-2021

Fix Request (8u): Backport to 8u requested because it is a part of 8u301-oracle. Review approval: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-May/013792.html
07-05-2021

Fix Request (11u) Should get backported for parity with 11.0.12-oracle. Applies cleanly except Copyright year change.
16-03-2021

Fix Request(16u): This fix will prevent AccessDeniedException being thrown on Windows machine due to delay in file deletion Regression risk is low Patch applies cleanly
25-02-2021

Changeset: ebdc80ea Author: Evan Whelan <ewhelan@openjdk.org> Committer: Daniel Fuchs <dfuchs@openjdk.org> Date: 2021-02-25 12:05:16 +0000 URL: https://git.openjdk.java.net/jdk/commit/ebdc80ea
25-02-2021

Moving to core-libs/java.util.logging for now as this may be another case where java.util.logging.FileHandler has to handle and choose the next sequence.
07-09-2020