问题。
在 Windows 7 上运行的一些用 Java 实现的守护进程将文件从一个目录复制到另一个目录,而源目录和目标目录都是由 Windows Server 2016 托管的网络共享。复制是使用 Apache Commons IO 完成的,偶尔会发生此过程失败,并出现以下堆栈跟踪和一条消息,读起来有点像“没有更多文件”:
java.io.IOException: Es sind keine weiteren Dateien vorhanden
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.WinNTFileSystem.canonicalize(Unknown Source)
at java.io.File.getCanonicalPath(Unknown Source)
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:642)
at org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:558)
at de.am_soft.osgi.dokliste.eingaenge.impl.internal.Eingang.copyFilesToDbxmlFolders(Eingang.java:283)
Apache Commons IO 在第 642 行使用以下代码,该行实际上只是以下 if
,而不是异常:
if (srcFile.getCanonicalPath().equals(destFile.getCanonicalPath())) {
throw new IOException("Source '" + srcFile + "' and destination '" + destFile + "' are the same");
}
所以问题不在于复制本身,而在于已经生成规范路径。使用进程监视器 1在守护进程运行的客户端也证明了这一点。以下是守护进程清楚地记录上述异常之前的最后一个事件,尝试使用 Logback 和东西发送错误邮件。该事件的结果(NO MORE FILES
)完全符合堆栈跟踪的错误消息:
10:12:06,6244515 integration.exe 6928 QueryDirectory \\HOST\SHARE$\DocBeam3\[...].zip NO MORE FILES Filter: 20191106-081920-[...].zip
此外,查看 ProcMon 的前几行,可以肯定异常仅发生在 destFile
上。在我的本地计算机上执行守护程序反而会导致以下记录事件(NO SUCH FILE
)始终:
19:08:03,7485947 java.exe 6232 QueryDirectory C:\Users\[...].zip NO SUCH FILE Filter: 20191022-143101-[...].zip
我调试了 native 方法并遇到了 lastErrorReportable
,它明确检查了一些特殊的错误代码并且不包含来自第一个事件的 ERROR_NO_MORE_FILES
,而它确实包含来自第二个的 ERROR_FILE_NOT_FOUND
:
if ((errval == ERROR_FILE_NOT_FOUND)
|| (errval == ERROR_DIRECTORY)
|| (errval == ERROR_PATH_NOT_FOUND)
|| (errval == ERROR_BAD_NETPATH)
|| (errval == ERROR_BAD_NET_NAME)
|| (errval == ERROR_ACCESS_DENIED)
|| (errval == ERROR_NETWORK_UNREACHABLE)
|| (errval == ERROR_NETWORK_ACCESS_DENIED)) {
return 0;
}
所以似乎每当 ERROR_NO_MORE_FILES
发生时,规范化路径就会因错误而中止,而不是像其他错误一样忽略它:
if (!lastErrorReportable()) {
if (!(dst = wcp(dst, dend, L'\0', src, src + wcslen(src)))){
goto err;
}
break;
} else {
goto err;
}
抛出的异常与我得到的非常吻合,给定的消息只是一个后备消息,在我的案例中没有使用:
if (rv == NULL && !(*env)->ExceptionCheck(env)) {
JNU_ThrowIOExceptionWithLastError(env, "Bad pathname");
}
补充观察。
现在有趣的是,守护进程并不总是在每个文件副本上失败,但只是有时,很少见。但如果它失败了,它似乎与目标目录中已经可用的其他目录和文件有关。虽然它们与守护进程完全无关,并且根据 ProcMon 的说法,它们不会被迭代或类似的东西,但它们的纯粹存在似乎已经产生了影响。如果我简单地删除所有这些文件和目录并以这种方式清空目标目录,复制立即再次成功。这很有趣,因为在我的本地设置的目标目录中有文件和目录似乎没有任何影响:复制永远不会失败,尤其是 ProcMon 记录的事件也永远不会是 ERROR_NO_MORE_FILES
。在清空发生问题的设置目录后,ProcMon 也会再次记录 ERROR_FILE_NOT_FOUND
。
问题。
因此,似乎出于某种原因,在某些当前未知的情况下,Windows 决定使用 ERROR_NO_MORE_FILES
作为调用 wcanonicalize< 使用的
。因为 Java 的异常列表中没有它,所以在这些情况下复制会失败,即使它看起来是完全有效的情况。否则我看不到任何真正的错误。FindFirstFileW
的最后一个错误
那么 ERROR_NO_MORE_FILES
应该添加到 lastErrorReportable
吗?如果是这样,我实际上需要问谁? :-)
最佳答案
此行为是由 Windows Server 2019 服务器(文件服务器)和以前版本的 Windows(客户端)之间的 SMB 不兼容引起的。目录元数据缓存的处理方式不同,这会导致在读取包含许多文件和文件夹的共享时出现此问题。
遗憾的是,Microsoft 尚未发布此错误的修复程序。
解决方法是使用此注册表设置在客户端禁用 SMB 元数据缓存:
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\DirectoryCacheLifetime=0 (DWORD)
关于java - 在 Windows 上规范化路径时,Java 是否需要支持 ERROR_NO_MORE_FILES?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58825588/