补全组件、问题信息命令:审查留下的 P2

Abierto
#14 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, powershell
Área
cli

Línea de trabajo

This is a bundle of review follow-ups across three commands: components (the .part resume and 416 handling, proxy selection, the --json and --accept-license check order), report-config, and collect-info (CRLF output from live/ shell commands, the shared 60-second WMI PowerShell process, the crash/ dedupe that uses filepath.Abs under %TEMP%). Start by reading how the resume logic and the WMI batch are written, and check which existing tests cover the crash/, mas/, live/ and logs/ branches. Splitting the list into separate issues before picking one item would make "done" easier to verify.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug P2

#9 的三个命令(components、report-config、collect-info)审查后留下的 P2:真实存在,但有绕过办法或影响面小,有空就修。

补全组件

  • 续传时收到 HTTP 416,会先删掉 .part,再看同一个镜像能不能从头给。如果这个镜像手里的文件本身就短,一份有效的半成品就被扔掉了,下一个镜像得从 0 开始。原脚本是保留 .part 的。
  • 镜像不支持断点续传、续传请求回了 200 和整个文件时,要清空 .part 从 0 计数(脚本的「这个镜像不支持断点续传,从头下载」)。这条路没有测试。
  • 代理选择(环境变量、Windows 系统代理)、接进客户端这两步没有测试;许可协议清单的整体时限和 16 MB 上限也没有测试。
  • --json 时必须给 --accept-license,这条是在解析根目录、检查状态之后,而且只在有组件缺失时才检查;应该和其余参数检查一起,提前到前面。

收集问题信息

  • live/ 里 shell 命令的输出是 LF 换行,脚本是 CRLF(adb shell 在 Windows 上会把换行转成 CRLF)。
  • 所有 WMI 查询放在一个 PowerShell 进程里,共用一个 60 秒的时限。只要有一类慢,所有靠 WMI 的行就都丢了。改成分开查,或者每类单独限时。
  • 两个和脚本逐行对照的测试场景,没有走到 crash/、mas/、live/、logs/ 的几个分支;每一节查询自己出错的情况,也只测了几节。
  • zip 里 crash/ 的条目没有逐字节核对,拷坏了也发现不了。
  • Ctrl+C 那条路(删暂存目录、返回 canceled)没有测试。
  • 崩溃转储那一节靠比较 filepath.Abs 的字符串来去重;%TEMP% 是 8.3 短路径时,用来去重的基准目录会算成两个(已经修了展开 8.3 短名那一层,这里是基准目录这一层)。
Lenguaje dominante
Go
Estrellas
0
Forks
1
Merge medio
2 h 42 min
PR fusionados (30 d)
13

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ModAVD/ModAVDManager

Todos los issues de ModAVD/ModAVDManager

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.