这个问题在互联网上有上千个帖子，但我找不到专门针对这个问题的答案GUI + 已验证移动/复制，因此它看起来不像重复的问题。
我想使用基于 GUI 的已验证移动/复制文件管理器。如果不是因为路径较长且需要验证，这会很容易 - 许多文件管理器允许哈希验证的文件移动/复制，许多文件管理器允许 UNC 并尝试解决长路径问题。我的主要设置是 Windows 8.1+FreeBSD 11 +Samba 4.6。
困难在于我还没有找到可靠的方法来实现这一点。即使是我常用的带有验证功能的长文件名管理器（如 XYPlorer 和 FasyCopy）也会在长路径上出现意外问题。
因此，我正在寻找理想情况下完全避免使用 Windows API（本地文件除外）的方法，这样我就可以管理远程文件而不必担心路径长度。但这里又很困难：基于 GUI 的 SCP（WinSCP、Filezilla）可以，只是它们在移动/复制后不会正式对源和目标进行哈希验证，而可能有助于将文件活动移动到服务器的 FISH 没有完整的 Windows 客户端。
我所追求的功能是在共享内、单台机器上的共享之间、不同机器上的共享之间以及 Windows 与共享之间的移动/复制/重命名，但在每种情况下，如果 Windows API 无法正确处理长路径，则避免使用它们进行远程文件访问。
我正在寻找的另一个好处是直接在服务器上和网络外执行服务器端文件活动，再次验证数据的物理写入或移动位置。
不幸的是，我发现即使声称可以处理长路径的程序似乎也做得不好。当我使用它们进行文件移动/复制时，它有点帮助，但我经常收到一堆错误，表明它们在实践中仍然无法处理长路径，我不想不断地怀疑我的数据复制/移动完整性或将东西移动到临时位置只是为了在远程存储实际上没有长路径问题的情况下对其进行操作。
我正在寻找一种方法来解决这个问题，但什么技术可能会有所帮助？在这种情况下，我不想减少文件路径或使用 CLI（这无论如何都不容易），使用驱动器号映射似乎没有多大帮助或需要太多字母，如果问题出在本地而不是远程文件上，使用“\\？\”会有所帮助，因为远程文件已经是 UNC，SCP 通常不包括显式验证，尤其是在 GUI 文件管理器中......
我还没有尝试设置 X Windows，因此当它是服务器文件时，我会直接在服务器上使用 GUI 进行操作，但这对 Windows 到远程/从远程操作没有帮助。我也没有查看允许复制扩展的文件管理器 - 例如那些允许将额外的复制/移动方法（如 ADB 或 shell 命令等效项）添加为脚本或类似内容的文件管理器。除此之外，我没有什么主意了。
我可能忽略了哪些选项？
答案1
不知道为什么还没有人提到这一点，但我发现更简单（虽然有点慢）的方法是压缩文件夹，复制压缩文件，然后解压缩。请注意，我使用的是第三方压缩程序，如 7zip，Windows 内置程序可能具有相同的文件路径限制。或者，您可以将嵌套较多的文件夹移动到更高级别的目录，将其复制过来，然后将其移回其嵌套位置。
不确定为什么会这样，但根据本文windows 的文件长度有上限姓名，但由于某种原因，在复制操作期间它会检查整个文件路径的长度。