If anyone wants to try to reproduce this, here is the Dockerfile I used to create the Windows docker image
# escape=` FROM mcr.microsoft.com/windows:1903 AS jdk17 # $ProgressPreference: https://github.com/PowerShell/PowerShell/issues/2138#issuecomment-251261324 SHELL [ "powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';" ] ENV JAVA_HOME='C:\Program Files\Java\jdk-17' # Install OpenJDK 17 ADD https://api.adoptium.net/v3/installer/latest/17/ga/windows/x64/jdk/hotspot/normal/adoptium?project=jdk C:\Temp\openjdk17.msi RUN Start-Process -Wait -FilePath msiexec -ArgumentList /i, "C:\Temp\openjdk17.msi", "'ADDLOCAL=\"FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome\"'", "'INSTALLDIR=\"C:\Program Files\Java\jdk-17\"'", /quiet, /norestart -Verb RunAs # Set JAVA_HOME and Update PATH to Java 17 RUN $newPath = ('{0}\bin;{1}' -f $env:JAVA_HOME, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); ` [Environment]::SetEnvironmentVariable('JAVA_HOME', ${JAVA_HOME}, [EnvironmentVariableTarget]::Machine); # Enable Windows Feature .NET Framework Runtime 3.5. Needed for installing Wix Toolset. RUN Set-Service -Name wuauserv -StartupType "Manual"; ` Enable-WindowsOptionalFeature -Online -FeatureName "NetFx3" -All; # Install Chocolatey RUN Set-ExecutionPolicy Bypass -Scope Process -Force; ` [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; ` Invoke-Expression ((New-Object System.Net.WebClient).DownloadString(' https://community.chocolatey.org/install.ps1')) # Install Windows 10 SDK. ENV SIGNTOOLPATH="C:\Program Files (x86)\Windows Kits\10\App Certification Kit" RUN choco feature enable -n allowGlobalConfirmation; ` choco install windows-sdk-10.1; ` $newPath = ('{0};{1}' -f $env:SIGNTOOLPATH, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); # Install WiX Toolset. ENV WIXPATH="C:\Program Files (x86)\WiX Toolset v3.11" RUN choco feature enable -n allowGlobalConfirmation; ` choco install wixtoolset; ` $newPath = ('{0}\bin;{1}' -f $env:WIXPATH, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); /Sverre fre. 18. feb. 2022 kl. 19:33 skrev Alexey Semenyuk < alexey.semen...@oracle.com>: > 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> > <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> > <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 > > > >
