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

Đang mở
  • Có gì không ổn?
#14 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go, powershell
Lĩnh vực
cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 短名那一层，这里是基准目录这一层）。
Ngôn ngữ chính
Go
Star
0
Fork
1
Merge trung bình
2 giờ 42 phút
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ModAVD/ModAVDManager

Tất cả issue của ModAVD/ModAVDManager

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.