升级到mineru>3.0后，ragflow提示找不到mineru解析后的文件，看了一下貌似是路径的问题

[lqstc]

🔎 Search before asking | 提交之前请先搜索

• I have searched the MinerU Readme and found no similar bug report.
• I have searched the MinerU Issues and found no similar bug report.
• I have searched the MinerU Discussions and found no similar bug report.

🤖 Consult the online AI assistant for assistance | 在线 AI 助手咨询

• I have consulted the online AI assistant but was unable to obtain a solution to the issue.

Description of the bug | 错误描述

升级到mineru>3.0后，ragflow提示找不到mineru解析后的文件，看了一下貌似是路径的问题

而ragflow容器里实际的路径是tmp/mineru/OpenClaw入门指南(1)_auto_pmj8qozx/auto/OpenClaw入门指南(1)_content_list.json，中间多了一个“auto"文件夹

而在mineru2.7.6上是正常的，请问是不是升级到3.0版本修改了保存路径

How to reproduce the bug | 如何复现

Operating System Mode | 操作系统类型

Linux

Operating System Version| 操作系统版本

Python version | Python 版本

3.12

Software version | 软件版本 (mineru --version)

>=2.5

Backend name | 解析后端

pipeline

Device mode | 设备模式

cuda

[dosubot]

Hi @lqstc! I'm Dosu and I’m helping the MinerU team.

这个 auto 子文件夹是 MinerU 的预期行为，不是 bug。MinerU 在输出时会使用 {output_dir}/{pdf_name}/{parse_method}/ 的嵌套目录结构，其中 parse_method 默认为 "auto"，所以会产生 auto/ 这个子目录 [1]。

实际上这个嵌套结构在 v2.7.6 中就已经存在了。3.0 的主要变化是新增了 output_paths.py 模块来标准化路径处理 [2]，以及包名从 magic-pdf 改为 mineru 等。

不同后端的输出子目录如下 [3]：

后端	parse_method	输出子目录
pipeline	auto (默认)	{pdf_name}/auto/
pipeline	txt	{pdf_name}/txt/
pipeline	ocr	{pdf_name}/ocr/
vlm-*	any	{pdf_name}/vlm/

所以正确的 content_list.json 路径应该是：{output_dir}/{pdf_stem}/auto/{pdf_stem}_content_list.json

这个问题需要在 RAGFlow 侧修复，让它适配 MinerU 的嵌套目录结构，而不是假设文件在平级目录下。另外值得注意的是，如果你是通过 FastAPI 调用 MinerU，v2.7.6 之后输出文件在 API 返回后会被立即删除 [4]，这也可能导致找不到文件的问题。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[myhloli]

mineru-api的接口参数没有变动，如果之前是通过读取本地缓存文件实现的，请改成通过接口获取解析结果。因为本地缓存路径不能保证一致且缓存文件会定期删除。

[lovetj]

我也遇到了同样的问题, 观察得到是mineru-api在返回文件的时候多了一层目录,之前mineru2版本返回的路径是xxx/auto,但是mineru3版本返回的是xxx/xxx/auto

[myhloli]

是返回的压缩包内文件夹层级有变动吗

[lovetj]

我看了一下,压缩包里面多了一个auto层级

[lovetj]

这个截图是mineru2版本的,路径只有一层auto

[myhloli]

那可能重构的时候哪里漏了，我晚点看一下

[myhloli]

我这边自测返回zip包的结构是正常的，你们是怎么调用api接口的

[lovetj]

我是ragflow集成mineru的

[myhloli]

这个是不是ragflow的插件有问题

[lqstc]

mineru-api
--host 0.0.0.0
--port 18000 启动的mineru

ragflow的设置接入mineru

[lovetj]

好像是,我进去看了一下,文件夹下面能找到对应的文件,但是ragflow仍然报错,奇怪的是为什么2版本可以,3版本不行,是3版本采用了异步的方式吗?没等mineru返回压缩包,接口就响应了

[lqstc]

但是我确定是升级后路径的问题，我今天下午用cherry studio测试了下，也是拿不到正确的文件。我就用ai写了一个兼容层，把拿到的zip文件解压去除auto路径，再打包，再传给cherry studio。就成功了

[lqstc]

# —— 5. 如果是 ZIP 流，剥离 auto/ 目录后再返回 ——
    if "zip" in content_type or "octet-stream" in content_type:
        cd = resp.headers.get("Content-Disposition", "attachment; filename=result.zip")
        try:
            body = _repack_zip_strip_auto(body)
            logger.info(f"[{ts}] 已剥离 auto/ 目录层，新 ZIP {len(body)} bytes")
        except Exception as e:
            logger.warning(f"[{ts}] 重打包 ZIP（去 auto）失败，回退透传原始 ZIP: {e}")
        return StreamingResponse(
            iter([body]),
            status_code=status_code,
            media_type="application/zip",
            headers={
                "Content-Disposition": cd,
                "Content-Length": str(len(body)),
            },
        )