ADDITIONAL SYSTEM INFORMATION :
Tested with Java 11 and 24

A DESCRIPTION OF THE PROBLEM :
This might appear to be a duplicate of JDK-8224095 or JDK-6956385, but it is not (or rather it is of the former which was closed as duplicate of the latter).

JDK-8224095 already reported it for file: URLs, but was closed as duplicate of JDK-6956385.

JDK-6956385 already reported it for jar:file: **and** file: URLs.

JDK-6956385 was closed as fixed in 22, but actually only attempted to fix it for jar:file: URLs and was **not** successful in doing so (I'll create a separate report for jar:file: URLs)

Using the https://github.com/jenkinsci/lib-file-leak-detector/ (but it also happens without, verified by trying to delete a file on Windows and not being able to, then investigating with the leak detector), you can see that with the three lines below a file descriptor is leaking because querying any "header" value like last modified or content type opens the input stream which then is never closed.

You have to get the actual input stream from the url connection (of which you maybe not even know that it is a file url connection) and close it, even if you are not at all interested in the input stream, just because the file url connection uses that input stream internally. That feels quite wrong and unintuitive.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Use the below code with an existing file
- Use the file leak detector or set a breakpoint after the third line and find that the file descriptor leaks
- Add `conn.getInputStream().close()` after the last line the leaked file descriptor is closed together with the input stream you never wanted to retrieve

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No file descriptor leaks
ACTUAL -
File descriptor is leaked

---------- BEGIN SOURCE ----------
URL url = URI.create("file:///path/to/some/existing/file").toURL();
URLConnection conn = url.openConnection();
conn.getLastModified();
---------- END SOURCE ----------