JDK-17: Wndows jpackage destination directory not writable

[Sverre Moe]

I executed our JDK11 docker image, which works fine with JDK11 and JDK14
(for jpackage support).
Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH.
Building our application now with JDK17 it still cannot write to the
"build/native" jpackage output directory.

Leads me to conclude something has changed in jpackage between JDK14 and
JDK17.
I modified my gradle configuration, to use jpackage from JDK14 when
packaging my JDK17 built application.
It works using JDK14 jpackage to package our JDK17 application.

Using the JDK17 jpackage directly in Windows works fine. It is only in the
Docker container that it does not work.

/Sverre



tir. 5. okt. 2021 kl. 11:55 skrev Sverre Moe <sverre.moe at gmail.com>:

> I ran cacls after the failed jpackage.
>
> C:\temp\my-javafx-application>cacls build
> C:\temp\my-javafx-application\build <Account Domain not found>F
>                              CREATOR OWNER:(OI)(CI)(IO)F
>                              <Account Domain not found>R
>                              CREATOR GROUP:(OI)(CI)(IO)R
>                              Everyone:(OI)(CI)R
>
> C:\temp\my-javafx-application>cacls build\native
> C:\temp\my-javafx-application\build\native <Account Domain not found>F
>                                     CREATOR OWNER:(OI)(CI)(IO)F
>                                     <Account Domain not found>R
>                                     CREATOR GROUP:(OI)(CI)(IO)R
>                                     Everyone:(OI)(CI)R
>
>
> As cacls was deprecated it suggested to use icacls instead:
>
> C:\temp\my-javafx-application>icacls build
> build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F)
>       CREATOR OWNER:(I)(OI)(CI)(IO)(F)
>       S-1-5-21-406077803-2019195645-689573112-513:(I)(RX)
>       CREATOR GROUP:(I)(OI)(CI)(IO)(RX)
>       Everyone:(I)(OI)(CI)(RX)
>
> Successfully processed 1 files; Failed processing 0 files
>
> C:\temp\my-javafx-application>icacls build\native
> build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F)
>              CREATOR OWNER:(I)(OI)(CI)(IO)(F)
>              S-1-5-83-0:(I)(RX)
>              CREATOR GROUP:(I)(OI)(CI)(IO)(RX)
>              Everyone:(I)(OI)(CI)(RX)
>
> Successfully processed 1 files; Failed processing 0 files
>
> Running attrib on the workspace, and build dirs:
>
> C:\Temp\my-javafx-application>attrib
> A                    C:\Temp\my-javafx-application\.description
> A                    C:\Temp\my-javafx-application\.gitignore
> A                    C:\Temp\my-javafx-application\build.gradle
> A                    C:\Temp\my-javafx-application\gradle.properties
> A                    C:\Temp\my-javafx-application\gradlew
> A                    C:\Temp\my-javafx-application\gradlew.bat
> A                    C:\Temp\my-javafx-application\Jenkinsfile
> A                    C:\Temp\my-javafx-application\packager.gradle
> A                    C:\Temp\my-javafx-application\README.adoc
> A                    C:\Temp\my-javafx-application\settings.gradle
> A                    C:\Temp\my-javafx-application\spotless.gradle
>
> C:\Temp\my-javafx-application>attrib build
>                      C:\Temp\my-javafx-application\build
>
> C:\Temp\meos-dashboard>attrib build\native
>                      C:\Temp\my-javafx-application\build\native
>
> /Sverre
>
> tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman <Alan.Bateman at oracle.com>:
>
>> On 05/10/2021 08:54, Sverre Moe wrote:
>> > With JDK 17, jpackage fails to write to the destination directory on
>> > Windows.
>> >
>> > It worked fine with JDK 11 (with jpackage from JDK14) and Docker.
>> >
>> > Only happens on Windows docker. Running directly on WIndows it works
>> with
>> > JDK 17.
>> >
>> > What has changed with jpackage that it no longer can write to the
>> > destination directory when running in Docker?
>> > Is it a regression/bug with jpackage?
>> >
>> I don't know what has changed in jpackage, maybe it didn't check for
>> write access previously. However, the error you are seeing suggests
>> there may be a lower-level issue, maybe a driver issue. It would be
>> useful if you could print out the DACL (using cacls is okay) and the DOS
>> attributes.
>>
>> -Alan
>>
>