JDK-8077261 : FileHandler(String pattern, boolean append) doesn't lock the file created
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.logging
  • Affected Version: 8u25,8u60
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-02-24
  • Updated: 2015-04-13
  • Resolved: 2015-04-13
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
FileHandler(String pattern, boolean append) doesn't lock the file created as with java 7

ADDITIONAL REGRESSION INFORMATION: 
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
to lock the file
ACTUAL -
file is not locked

REPRODUCIBILITY :
This bug can be reproduced always.


Comments
Resolving as not an issue. The lock file is removed when the FileHandler is closed. Since the code in attachment doesn't close the FileHandler, the lock file is left behind. JDK-8048020 (which was pushed in 8u40) makes it possible to reuse the lock file, if it is not locked. If the lock file isn't reused, it might mean that the underlying OS hasn't released the lock when the process exited. Then it would all depend on what the underlying operating system does when a process locks a file channel and exits without releasing the lock. I have run the attached program on windows 7 with 8u31, 8u40, and 8u60 b10. 8u31 does have the problem described, but this is because of JDK-8048020. I could not reproduce the issue with 8u40, or 8u60 b10. This is 1. a user error, because FileHandlers must be explicitly closed before exiting, and 2. a probable duplicate of JDK-8048020. Feel free to reopen if you have more data proving that this analysis is wrong.
13-04-2015

The class in attachment does this: {code} import java.io.IOException; import java.util.logging.FileHandler; public class FileHandle { public static void main(String[] args) throws IOException { new FileHandler("./file_%g_%u.log", 10000, 100, true); } } {code} It is a user error to exit the VM without closing the FileHandler. In such a case I suspect that the behavior could be system specific.
13-04-2015

1) Run the attached test cases (FileHandle.java) The program generates a new file and append the file on subsequent run. 2) Tested this on Windows 7 and Linux-X64 with JDK 7u75, 7u80, 8u25, 8u31, 8u40, 8u60 ea b07, 9 ea b57. The test run fine with all JDK versions except JDK 8u60 ea b07. The issue is reproducible with JDK 8u60, but works fine with all other JDK versions including subsequent JDK 8 (8u40, 8u60 ea, 9 ea) versions. JDK Versions Outcome **************************************************************************************** 7u75: OK 7u80: OK 8u25: FAIL 8u31: OK 8u40: OK 8u60 ea b07: FAIL 9 ea b57: OK ****************************************************************************************** Result of the testcase with 8u25 and 8u60: generates following files: file_0_0.l0g file_0_0.l0g.lck file_0_1.log file_0_1.log.lck ...................... Result of the testcase with 7u75 and 8u40: file_0_0.l0g file_0_0.l0g.lck ...................... ***************************************** Conclusion: This seems a regression in JDK 8u60.
08-04-2015