fix: 手动粘贴微信路径仍提示找不到数据（Windows 为主，mac 同样受影响） - #26
Merged
Conversation
Reported from the field (Windows): pasting the folder WeChat's 「文件管理」 shows still ends in "已保存路径，但里面还没找到 wxid_*/db_storage". Two independent causes, both reproduced with fixtures before fixing. 1. `_windows_xwechat_variants` fans a pasted path out into a FIXED list of wrapper layouts (`Tencent/xwechat_files`, `Documents/xwechat_files`, …). Anyone whose storage folder is named anything else pastes a perfectly correct path and is still told nothing was found. Measured: of 8 realistic layouts, 5 failed — including `<paste>/WeChat/xwechat_files` and `<paste>/Weixin/xwechat_files`, which the list nearly covers but not quite (it has `Tencent/WeChat/...` but no bare `WeChat/...`), plus any custom or Chinese-named folder. Rather than another round of whack-a-mole on folder names, search under what the user actually gave us: `_descend_for_account_dirs()` does a bounded BFS (depth 4, 3000 dirs, 8s wall clock) and only runs for user-supplied roots, and only after the shallow lookup found nothing. The wall clock is not redundant — each listdir can burn `_safe_listdir`'s 1.5s timeout, so a count-only budget could still stall a request for minutes on a dying disk. 2. `_looks_like_account_dir` rejected every directory whose name starts with "all". That was meant for the shared `all_users` folder, but it silently swallowed real accounts whose WeChat alias starts with those letters (allen_9f3a, ally_1a2b). Such a user could paste the correct path at every level and never be found. Now an exact-match set, with `all users` added. Both fixes apply to macOS too — the mac branch never had the wrapper variants at all, so custom layouts failed there just as hard. Adds tests/test_wechat_path_discovery.py (9 cases: layout variants, every level a user might paste, all-prefixed accounts, and guards proving the descent stops at the depth budget, stops at account dirs, and still rejects empty shells) and a Tests workflow — the repo had no test CI, so the existing suite was never run automatically. Windows is in the matrix on purpose. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sgaofen
added a commit
that referenced
this pull request
Aug 5, 2026
Ships the two fixes that were sitting on main with no release behind them: - paths: find WeChat data under a user-pasted path of any layout, and stop rejecting accounts whose alias starts with "all" (#26) - qq_store: concurrent perf-index builds no longer race into "database is locked" and silently skip the indexes (#24 follow-up) Also corrects Cargo.lock, which still pinned the murmur package at 0.4.2 while Cargo.toml said 0.4.3. README video links intentionally still point at the v0.4.3 release — that is where the tutorial mp4s live, and the release workflow only uploads build artifacts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
起因是 B 站反馈：手动输入了微信地址还是找不到目标。复现后发现是两个独立的原因，都先用 fixture 稳定复现、再动手改。
1. 硬编码的目录名列表覆盖不到用户实际的存放位置
_windows_xwechat_variants把用户粘贴的路径展开成一组固定的包装层级（Tencent/xwechat_files、Documents/xwechat_files…）。只要用户的存储文件夹不叫这几个名字之一，粘贴的路径完全正确也会被判定为找不到。而微信「文件管理」里显示的正是用户自己选的存储目录，所以这条路径几乎必然落在列表之外。
实测 8 种现实布局，5 种失败：
xwechat_filesTencent/xwechat_filesTencent/Weixin/xwechat_filesWeChat/xwechat_filesWeixin/xwechat_fileswechatData/xwechat_files微信文件/xwechat_filesdata/wx/xwechat_files注意
WeChat/xwechat_files和Weixin/xwechat_files—— 列表里有Tencent/WeChat/xwechat_files，却没有单独的WeChat/xwechat_files，差一层就全盘失效。改法：不再往列表里继续加名字（治标且永远加不全），而是直接在用户给的路径下面搜。新增
_descend_for_account_dirs()，有界 BFS（深度 4 / 3000 个目录 / 8 秒墙钟），只对用户显式粘贴的路径生效，且只在浅层查找失败后才触发。墙钟上限不是冗余的：这里每次 listdir 最坏会耗掉
_safe_listdir自己的 1.5 秒超时，只按目录数计预算的话，遇到坏盘或掉线的网络盘仍可能把请求拖住几分钟。2. 账号名以
all开头的用户永远找不到_looks_like_account_dir里有一句name.startswith("all")，本意是跳过微信自带的共享目录all_users，但它把真实账号也一起吞了——微信号别名叫allen_9f3a、ally_1a2b的用户，粘贴任何层级的正确路径都会被告知找不到。已改为精确匹配集合，并补上
all users变体。原来要挡的all_users仍然挡得住（有测试覆盖）。macOS 同样受影响
mac 分支压根没有包装层级展开，所以自定义目录名在 mac 上失败得更彻底。这两个修复对 mac 一并生效。
测试
新增
tests/test_wechat_path_discovery.py，9 个用例：布局变体、用户可能粘贴的每一个层级（父目录 / xwechat_files / 账号目录 / db_storage / .db 文件）、all开头的账号名，以及三条护栏——下探不越过深度预算、不进入账号目录内部（真实微信数据下面有几万个媒体文件）、仍然拒绝没有 .db 的空壳目录。同时新增
Testsworkflow：这个仓库此前没有任何测试 CI，原有的 2 个测试从来没被自动跑过。矩阵里特意带上 Windows —— 这些用例本来就是为 Windows 布局写的。本地在零依赖的干净 Python 3.11 venv 里全部通过（9/9，加上原有 2 个共 11 个）；另外跑了性能验证：空配置 11ms 不触发下探，最坏情况（又宽又深且无微信数据的目录）406ms 有界返回。
🤖 Generated with Claude Code