views:

487

answers:

2

We have a Java application that includes components that run as SYSTEM on Windows machines. On Windows 7 x64, one component fails when trying to unpack the jnidispatch library:

Exception in thread "main" java.lang.Error: Failed to create temporary file for
jnidispatch library: java.io.IOException: The system cannot find the path
specified
    at com.sun.jna.Native.loadNativeLibraryFromJar(Native.java:600)
    at com.sun.jna.Native.loadNativeLibrary(Native.java:550)
    at com.sun.jna.Native.<clinit>(Native.java:87)
    at falcon.util.vmware.VcmdTwo.loadLibraries(VcmdTwo.java:53)

Copied below is a snippet of the comments from the Native class from the jna library:

When JNA classes are loaded, the native shared library (jnidispatch) is loaded as well. An attempt is made to load it from the system library path using {@link System#loadLibrary}. If not found, the appropriate library will be extracted from the class path into a temporary directory and loaded from there.

OK, so far so good: Java is trying to unpack jnidispatch.dll into whatever java.io.tmpdir points at. The problem seems to be that java.io.tmpdir points to C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ for that particular process. This directory exists and SYSTEM has Full Control. However, extraction of the jnidispatch DLL to that directory always fails. If I modify the code in our app to manually write files to that same directory, the writes succeed.

I've looked over the relevant Java and JDK code and don't see any obvious misbehavior, so I'm forced to conclude that this is some weird Win7 UAC-related bug, but darn if I can figure out what it is. Any suggestions would be most welcome.

A: 

Have you tried setting java.io.tmpdir to a different venue, as discussed here?

trashgod
A: 

Are you 100% certain that it is writing to where you think it is writing? Given that if you modify the program to force it to write to there and it works it sounds like you are trying to write to another directory.

TofuBeer
Bingo. After some digging with procmon, I found two things. First, jnidispatch was being unpacked correctly. Second, the actual failure was caused by a third-party component that we use trying (and failing) to write a brief log file in c:\windows\sysWOW64\config\systemprofile\AppData\Local\Temp, which didn't exist. We've bugged this with the component owners and added a workaround to create that dir when it doesn't exist, and all is well. Thanks!