OpenNTF/org.openntf.nsfodp

Investigate AccessDeniedExceptions in many operations on Windows

Closed this issue · 5 comments

jesse-gallagher commented

This may currently hit access-denied exceptions even when not actively working with the odp folder in another app.

jesse-gallagher commented

This can happen when generating/exporting an ODP when the destination exists, and can also happen when working with the scratch space, even though createDirectories should be safe:

Caused by: java.nio.file.AccessDeniedException: c:\Git\icrc\buildtest\target\nsf
odpequinox\plugins
        at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsE
xception.java:89)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsExc
eption.java:103)
        at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsExc
eption.java:108)
        at java.base/sun.nio.fs.WindowsFileSystemProvider.createDirectory(Window
sFileSystemProvider.java:509)
        at java.base/java.nio.file.Files.createDirectory(Files.java:690)
        at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:79
7)
        at java.base/java.nio.file.Files.createDirectories(Files.java:783)
        at org.openntf.nsfodp.commons.osgi.EquinoxRunner.start(EquinoxRunner.jav
a:111)
        at org.openntf.maven.nsfodp.equinox.AbstractEquinoxTask.run(AbstractEqui
noxTask.java:195)
        ... 25 more
jesse-gallagher commented

For the parts relating to the target/nsfodpequinox directory, it might work to put a random number in the directory name. It wouldn't fix trouble if target itself is part of the problem, but it'd lower the churn with the subdirectories.

mpradny commented

The problem seems to be caused by the sequence of setWorkingDirectory and start calls, where the first one creates the directories and the second tries to delete them and recreate them.