Why does Java application fail to run on Windows if jar file has L-attribute/reparse point

Question

I'm really hoping that the following rings a bell with someone as we're running out of ideas. Answers or suggestions on how to further diagnose would be much appreciated.

We have a Java app that has been running with no problems for 18 months. It is now moving to a new platform running Windows Server 2019 Standard as a VM. On first install everything runs correctly, but periodically the application fails to start and can then only be fixed by re-copying all the jar files. This is temporary as eventually it fails again.

After a lot of monitoring we noticed that there is a Windows process that periodically sets the "L" file attribute on all the files and also creates reparse data. This should not be an issue but once this has happened, the JVM is unable to start the application. (any Windows-whizzes have an idea on what does this?)

A key point is that the app is started by specifying JPMS parameters such as:

java -p MyApp.jar;MyApp_mods -m  mymodule/mypackage.StartGUI

This runs well unit the "L" attribute is set on the jar files and then fails with message:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module format not recognized: MyApp.jar

Renaming MyApp.jar to something else and then copying it back to MyApp.jar fixes the problem as it creates a file without the L attribute and the reparse data (until the process re-applies it)

This behaviour does not just apply to this one operation, but to any where the module system is used such as:

 java --list-modules any-jar-in-the-app.jar    

Interestingly(!) if we try a simpler, non-modular app and run as:

java -jar MySimpleApp.jar

then the app runs correctly even with the L attribute set.

Clearly we don't fully understand, but it looks as if running via the module system somehow means that files with the L attribute/reparse data cannot be read (?)

We've tried both the OpenJDK hotspot and OpenJ9 JVMs in various versions but with the same result. Any ideas?

Answer 1

This is only a partial answer but it's worth showing in case someone has the same problem. I'll try to update when there's more info but it could be a while. (update 19/4/21 - bug reported. See JDK-8265439)

As Naman pointed out, the issue is in the JPMS code that looks for module-info in the .jar files. Part of that code gets the file attributes and checks attr.isRegularFile(). If this is false, then the java.lang.module.FindException: Module format not recognized is thrown.

Whenever the Windows file management process runs it creates a reparse point and sets the L attribute on the file. After this, attr.isRegularFile() returns false.

I'm unsure as to exactly what the process is but the Microsoft documentation for reparse tag 0x9000601A is: IO_REPARSE_TAG_CLOUD_6 - Used by the Cloud Files filter, for files managed by a sync engine such as OneDrive. Server-side interpretation only, not meaningful over the wire.

In Java, the class BasicFileAttributes is implemented for Windows by sun.nio.fs.WindowsFileAttributes. Inspection of the source confirms that isRegularFile() will return false if the FILE_ATTRIBUTE_REPARSE_POINT bit is set in the file attributes.

None of this causes a problem if loading .jar files from the classpath so that is the workaround - don't run using JPMS. Having spent a month modularising the app this is not ideal but it works for now.

I think this has to be a bug in JPMS as it makes no sense that .jar files can be loaded via a classpath and not from a module path. I'll gather more info and report it, although reproducing it could be difficult.

Thanks for the responses - they all helped.

Answer 2

I guess this is a bug.

Reparse Point attribute is used by the NTFS filesystem for implementing symbolic links, implementing mount points and implementing other filesystem techniques like auto moving of less used files to long term storage areas (compressed files/filesystems) / or devices (for example tapes).

"Reparse points and extended attributes are mutually exclusive. The NTFS file system cannot create a reparse point when the file contains extended attributes, and it cannot create extended attributes on a file that contains a reparse point."

So a workaround would be to set an extended attribute at the file to prohibit this behavior / bug.

PS I guess your Windows Server runs some kind of "auto compressing/moving less used files"-service, deactivate this service, when possible.