原 WSL VHDX：

E:\WSL\Ubuntu-24.04\ext4.vhdx

Windows 报错：

无法启动分发，因为其虚拟磁盘已损坏。
Wsl/Service/CreateInstance/WSL_E_DISK_CORRUPTED

这个 VHDX 是动态磁盘，Windows 文件大小约 44 GB，但虚拟容量是 1 TB。

后来检查宿主 E 盘，发现 E 盘本身是 exFAT（据说这种格式很不适合），并且：

chkdsk E: /scan

报告：

Windows 在磁盘上发现错误
检查卷位图时发现损坏
文件存在交叉链接
坏扇区 0 KB

所以目前怀疑是宿主 exFAT 文件系统损坏，进而破坏了 WSL 的 ext4.vhdx。

我另外安装了 Debian WSL 作为救援系统，并以 bare 方式挂载旧 VHDX：

wsl --mount "E:\WSL\Ubuntu-24.04\ext4.vhdx" --vhd --bare

旧盘在 Debian 中对应：

/dev/sdd

新的 Debian 是另一块设备，未对其操作。

最初：

e2fsck -fn /dev/sdd

显示：

Bad magic number in super-block
Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode

这里我犯了一个比较严重的错误（这是GPT搞出来的，我对技术是完全不懂，他妈的）：之后执行过一次：

e2fsck -f -y /dev/sdd

它出现过：

Root inode is not a directory. Clear? yes
Root inode not allocated. Allocate? yes
/lost+found not found. Create? yes
Recreate journal? yes

所以 ext4 元数据显然已经进一步被修改。之后 debugfs 看到根目录基本只剩：

/
└── lost+found

而 lost+found 为空。

从那以后，我已经停止一切对旧 /dev/sdd 的写操作，当前只做只读恢复。

现在正在使用 PhotoRec 对整个 /dev/sdd 做 raw carving：

Disk /dev/sdd - 1099 GB / 1024 GiB (RO)

恢复结果写到健康的 D 盘：

D:\HermesRecovery.1
D:\HermesRecovery.2
...

PhotoRec 会不断生成新的 HermesRecovery.N 目录。

目前已经恢复出 6 万多个文件，包括大量：

.txt
.py
.gz
.sqlite
.java
...

我的真正目标是恢复原来的：

~/.hermes/skills/

尤其是我自己通过 Hermes /learn 或自动学习生成的 custom skills。

问题是 PhotoRec 不保留原始文件名和目录结构，因此原本类似：

~/.hermes/skills/my-skill/
├── SKILL.md
├── scripts/xxx.py
└── references/xxx.txt

现在可能变成：

f123456.txt
f123789.py
f124000.txt

目前我已经从恢复文件中识别出约 214 个真正符合 Hermes SKILL.md 格式的文件，其典型格式为：

name: xxx
description: xxx

但是这些 214 个里大量是 Hermes 官方/公共 skill，例如：

llama-cpp
tensorrt-llm
stable-diffusion
github
pdf
xlsx
powerpoint
playwright-cli
browser-use
...

因此目前还没有确认找到我自己的 custom skill。

我还尝试寻找 Hermes 的一些辅助数据：

~/.hermes/skills/.usage.json
~/.hermes/skills/.bundled_manifest
~/.hermes/skills/.hub/lock.json
~/.hermes/skills/.curator_ledger.jsonl
~/.hermes/state.db
~/.hermes/skills/.curator_backups/.../skills.tar.gz

目前结果如下：

真正 .usage.json：未找到
真正 Hermes state.db：未找到
curator ledger：未确认找到
custom skill：未确认找到
真正 SKILL.md 内容：已找到约 214 个，但看起来主要是官方/公共 skills

找到了 7 个 SQLite 文件，但检查 schema 后都不像 Hermes state.db：

SQLite 候选: 7
Hermes-like DB: 0
skill_manage / /learn 命中: 0

还找到过一个包含 SKILL.md 的 .gz：

package/lib/tools/skills/playwright-cli/SKILL.md
package/lib/tools/skills/playwright-component-testing/SKILL.md
package/lib/tools/skills/playwright-trace/SKILL.md

但这个明显是某个软件包 archive，不是 ~/.hermes/skills 的备份。

现在主要想请教以下问题：

在 ext4 元数据已经严重损坏、而且 root inode 曾被错误的 e2fsck -y 重建过的情况下，除了 PhotoRec/file carving，还有没有更适合恢复原目录结构、inode 或文件名的方法？
有没有办法从 ext4 的残余 inode、directory entry、journal、backup metadata 中，针对性恢复原来的：
/home/<user>/.hermes/skills/

而不是全盘 raw carving？

PhotoRec 已经恢复出大量 SKILL.md 内容，但没有目录结构。有没有比较可靠的方法判断哪些是：
Hermes bundled skill
Hub 安装的 skill
用户 /learn 创建的 custom skill
agent 自动生成的 skill
如果 .usage.json、state.db、.curator_ledger.jsonl 都没恢复出来，还有没有 Hermes 自己留下的其他 provenance/index/cache 能帮助确定 custom skill 名称？
PhotoRec 当前扫描的是 1 TB 逻辑 VHDX，但实际动态 VHDX 文件只有约 44 GB。有没有更高效的方法只扫描实际已分配的 VHDX blocks，而不是把整个 1 TB 虚拟地址空间扫完？
如果有人熟悉 ext4, WSL2 ext4.vhdx, PhotoRec/TestDisk, debugfs, extundelete, ext4magic 或 Hermes Agent，非常希望能给我一个以“恢复原来的 custom skills”为目标的方案，而不是恢复整个 Ubuntu。

目前旧 VHDX 已经停止写入，PhotoRec 也是只读扫描，恢复结果全部写到 D 盘。

如果需要，我可以继续提供：

lsblk
dumpe2fs/debugfs 输出
e2fsck 日志
PhotoRec 当前进度
恢复出来的 SKILL.md 示例
恢复出来的 SQLite schema
VHDX 文件信息

我现在最想避免的是继续对原 VHDX 做任何可能破坏数据的写操作。