Windows Desktop: LibreOfficeKit 在长路径下转换失败，短路径 Junction 可正常通过 #7485
Replies: 3 comments 1 reply
|
你那份 A–F 的组合测试很有说服力 —— 把变量收敛到「dsh root」一个上，这是这个报告最有价值的部分。我补两个可算的数字，和一条我认为最该先做的判定实验。 数字：打包布局比 prepared 布局深 60 个字符按你给的两条路径（相对 差 60 字符，正好是中间多出来的 叠到你的源码根 ⇒ 两个都没有越过 260。所以"安装路径本身太长"解释不了你的现象 —— 越过阈值的必须是参与转换的另一个路径（被转换的文档、或 LibreOfficeKit 自己落临时文件/用户 profile 的那个目录）。这一点值得单独量一次，因为它决定了修法是"缩短安装路径"还是"缩短临时目录路径"。 一个我可以查、你也能查的不对称长路径（>260）在 Windows 上要同时满足两件事：机器注册表 我在本仓库 请顺手回一句： 最该先做的判定实验：把真实路径打出来在失败的那一次上，量出真正交给转换器的那条绝对路径，而不是安装路径：
为什么值得按上面那样把它钉死DSH 这一侧把转换失败统一映射成 |
|
按照你说的，我重新测试了一次。 下面是结果，希望对后续排查有帮助。 测试目录系统长路径设置这次 packaged runtime 仍然在 DOCX 转换时失败： 失败时 LibreOfficeKit 实际收到的路径inputoutputprofileprocess cwdexecutableprogramDirectoryLibreOfficeKit engine tree 路径统计我也重新统计了失败位置下 LibreOfficeKit engine tree 内部文件的完整路径长度： 所以这次可以确认：
对照结果之前同一套测试中： 另外，之前把同一份 packaged engine 通过 Junction 暴露到： 后，Office smoke 也可以通过。 以上是这次重新测试拿到的实际数据。 |
|
我在自己的构建上独立复现了这个现象,结论与 修正:决定成败的是文件的路径,不是 engine 根的路径按 engine 根计算确实都不过 260,但越限的是它内部最深层的文件。对同一份
(源码根 最深的一条是: 所以不需要引入"被转换文档的路径"或"临时/profile 目录"来解释:打包布局让 LibreOffice 自身的资源文件越过了阈值。 顺带交叉验证:你们给的是 回答
|
你的修正成立，我那处算术确实测错了对象——谢谢你把它钉死1. 我接受这条修正我当时的算法是按 engine 根（
这也顺带解释了Junction 为什么有效：Windows 的 2. 你那两组证据都很有价值，建议保留
3. 建议再加一行证据（会让结论无法反驳）在你那张表里再加一列 4. 版本提醒（这条现在很重要）你环境写的是 看有没有触碰打包布局的提交；若没有，你这条在 rc.2 上仍然成立，可以照现在的形式提；若有，请把版本基线改成 rc.2 再复现一次。 5. 一句总结你的两条结论（决定因素是 |
Uh oh!
There was an error while loading. Please reload this page.
环境
dsh-v0.1.7-alpha.1win32-x6444.0.026.15.324.18.111.7.0源码目录：
构建命令：
pnpm.cmd run package:desktop:win:x64:unsigned问题现象
Prepared runtime 的 Office 转换测试可以通过：
但 packaged runtime 在 DOCX -> PDF 时失败：
失败发生在：
隔离测试
为了确认问题来源，我做了以下组合测试：
结果非常稳定：
因此决定结果的因素是
dsh root本身，而不是：已排除 native package 内容差异
比较以下两个目录：
比较结果：
因此可以排除：
已排除 app.asar 虚拟路径直接传给 native helper
最初怀疑
require.resolve()在 Electron 中返回了：然后这个虚拟路径被传给 native helper。
但实际运行时打印出的路径是：
所以最终传给 native helper 的路径已经是：
对应的真实物理路径。
不是：
虚拟路径。
路径长度统计
对 LibreOfficeKit engine 的完整绝对路径进行统计后，发现 prepared 和 packaged 的差异很大。
大致结果：
packaged engine root：
其中
libreoffice-kit.exe本身仍然可以正常启动，所以并不是 executable path 直接无法访问。但 LibreOfficeKit 初始化以及实际文档转换过程中，还会继续访问：
以及其它更深层资源。
因此内部实际访问路径会比
programDirectory本身更长。决定性 A/B 测试
为了确认是否与路径长度有关，我没有修改 packaged LibreOfficeKit native package 的任何文件。
而是将完全相同的 packaged engine 通过 Windows Junction 映射到短路径：
例如：
然后让 runtime 使用：
其它条件保持不变：
结果：
也就是说：
这个结果目前是最有判别力的证据。
当前判断
目前看起来，问题高度集中在 Windows 下 LibreOfficeKit / LibreOffice 内部对长路径的处理。
Native helper 本身可以正常启动，但 LibreOffice 初始化、Writer/filter/config/resource 加载过程中会访问更深层的资源路径。
当完整绝对路径过长时，某个内部 Windows API 或 LibreOffice 组件可能无法正常处理，最终 native helper 只返回：
所以表面看起来像 LibreOfficeKit 初始化异常，但实际可能是内部资源路径访问失败。
为什么 prepared runtime 正常，而 packaged runtime 失败
Prepared engine 路径较短：
Packaged engine 路径明显更深：
两份 native package 内容完全一致。
真正发生变化的是：
这也与前面的 A-F cross test 完全一致：
建议修复方向
可以考虑让 Windows Desktop packaging 将 LibreOfficeKit native engine 放到更浅的物理目录，例如：
或者：
而不是当前的：
然后让
@deepseek-ai/libreoffice-kit或 Desktop runtime 显式使用这个 native engine physical path。例如目标结构可以类似：
而不是：
这样可以显著降低 Windows 下 LibreOfficeKit 内部资源的完整绝对路径长度。
相比要求用户启用 Windows long-path system setting，这种方式可能更可靠，因为 LibreOffice 及其依赖组件未必全部使用支持 long path 的 Windows API。
其它已做的检查
当前已经检查或排除：
最终只有：
可以稳定改变结果。
All reactions