在 Win7 上以 SYSTEM 身份运行时写入临时目录失败
我们有一个 Java 应用程序，其中包含在 Windows 计算机上作为 SYSTEM 运行的组件。在 Windows 7 x64 上，尝试解压 jnidispatch 库时，一个组件失败：
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)
下面复制的是 jna 中 Native 类的注释片段 图书馆：
加载 JNA 类时，本机共享库 (jnidispatch) 是 也已加载。尝试从系统库路径加载它 使用{@link System#loadLibrary}。如果没有找到，则相应的库 将从类路径中提取到临时目录中并且 从那里加载。
好的，到目前为止一切顺利：Java 正在尝试将 jnidispatch.dll 解压到 java.io.tmpdir 指向的任何位置。问题似乎是 java.io.tmpdir 指向该特定进程的 C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ 。该目录存在并且 SYSTEM 具有完全控制权。但是，将 jnidispatch DLL 提取到该目录总是失败。如果我修改应用程序中的代码以手动将文件写入同一目录，则写入会成功。
我查看了相关的 Java 和 JDK 代码，没有发现任何明显的不当行为，所以我不得不得出结论，这是一些与 Win7 UAC 相关的奇怪错误，但我是否能弄清楚它是什么。任何建议都将受到欢迎。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否 100% 确定它正在写入您认为正在写入的位置？鉴于如果您修改程序以强制它写入那里并且它有效，听起来就像您正在尝试写入另一个目录。
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.
您是否尝试过将 java.io.tmpdir 设置为不同的地点，如所讨论的这里？如此处和此处< /a>，您可以更改
createTempFile()启动 Java 虚拟机时：因为这种方法可能不安全 和特定于主机平台，仅应在跟踪实际问题时使用它，对于 示例。
Have you tried setting
java.io.tmpdirto a different venue, as discussed here? As noted here and here, you can change the default used bycreateTempFile()when starting the Java Virtual Machine:Because this approach is potentially insecure and host platform specific, it should only be used while tracking down the actual problem, for example.
由于以下原因，写入文件可能会失败：
1. 用户权限（继承人为处理）。
2. 损坏的文件（已经存在）。
3. 文件同时被另一个应用程序访问。
4. 文件被反恶意软件/防病毒软件锁定。
我遇到了问题。奇怪的是，我的防病毒软件检测到 jndispatch.dll 文件为不干净的文件，并将其转储到其保管库中。
可能内置的Windows Defender正在做同样的事情。
查看！
Writing a file could fail due to following reasons:
1. user permission/s (inheritance manhandled).
2. corrupt file (already present).
3. file being accessed by another application at the same time.
4. file being locked by anti-malware / anti-virus software.
i had the problem. strangely my antivirus detected jndispatch.dll file as an unclean file and dumped it to its vault.
may be the inbuilt windows defender is to doing the same thing.
check out!