Hi Sverre,
Interesting, I don't see changes in jpackage code related to the issue.
In particular jdk.jpackage.internal.IOUtils.writableOutputDir() function
is the same in JDK14, JDK17, and mainline.
- Alexey
On 2/18/2022 8:31 AM, Sverre Moe wrote:
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....@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.bate...@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
