@@ -207,7 +207,7 @@ files whose output is deterministic (`api`, `bitwise`, `calls`, `closure`,
 **byte for byte**. Five more (`cstack`, `gc`, `literals`, `locals`,
 `constructs`) print things that vary with the implementation or with a random
 seed, so they are only asserted to run to completion and print `OK` — the reason
-for each is listed under *Phase 10* below. 848 tests green, JaCoCo line coverage
+for each is listed under *Phase 10* below. 850 tests green, JaCoCo line coverage
 0.90 against a 0.89 gate. (The upstream-suite gate needs `LUA54_TESTS` or
 `target/lua54-tests`; without a test directory that whole class **skips itself**,
 so a green run on a machine without it is 25 tests weaker than it looks.)
@@ -1601,11 +1601,17 @@ seek offset"*, which falls through `errnoOf`'s catch-all into `EIO`. Seeking
 **past** EOF is legal and returns the new position — easy to block by accident
 while fixing this.
 
-Two things are deliberately absent. `fopen` on a **directory** succeeds on both
-macOS and glibc but then behaves differently on read, and the JVM will not open a
-directory as a stream at all. And `print` writes to the C-level `stdout`, so it
-is *not* redirected by `io.output` — a script that assumes otherwise produces
-two different wrong answers.
+One thing is deliberately absent: `print` writes to the C-level `stdout`, so it
+is *not* redirected by `io.output` — a script that assumes otherwise produces two
+different wrong answers.
+
+`fopen` on a **directory** used to be listed here as absent too, and that was a
+mistake: it is a single POSIX rule (`open(dir, O_RDONLY)` succeeds, `O_WRONLY`
+gives `EISDIR`, and the first read fails with `EISDIR`), it is the same on macOS
+and glibc, and the JVM simply refused to model it. It is now modelled — see
+*The directory bug* below. The one part that is genuinely not comparable is
+`seek("end")` on a directory, which returns the directory's own size (64 here),
+a filesystem fact rather than a Lua one.
 
 #### The `os.time` sweep: `lua_tointegerx` converts strings
 
@@ -1791,10 +1797,15 @@ It also found one place where C and Java simply disagree about a path:
 `cannot open : No such file or directory`; Java resolves the empty path to the
 current directory and fails while *reading*, giving `Is a directory` — which we
 turned into `Input/output error`. The empty path is the only case where the two
-judge a path differently, so it gets `ENOENT` by C's rule. **Directories
-themselves are fine and must not be "fixed":** `loadfile("/tmp")` succeeds at
-`fopen` in C and fails at *read*, so it takes the other branch —
-`cannot read /tmp: Is a directory`.
+judge a path differently, so it gets `ENOENT` by C's rule.
+
+Directories were claimed here as "fine, must not be fixed" — and that claim was
+wrong, which is the point worth keeping: **it was written from reading the C
+source, not from running the reference.** `loadfile("/tmp")` does succeed at
+`fopen` in C and fail at *read* — but this implementation was reporting
+`cannot open /tmp: Input/output error`, i.e. the *other* branch, because Java's
+`Files.readAllBytes` throws at open. Measuring it (see *The directory bug*) turned
+one wrong sentence into a real bug across five entry points.
 
 #### A sweep that came back clean: `load`'s reader contract
 
@@ -2160,6 +2171,41 @@ All 39 came back byte-identical — those branches were **correct but never
 executed**. Their value is as a regression net: change `read("n")`'s prefix
 handling or the write-buffer threshold and this goes red immediately.
 
+#### The directory bug: one POSIX rule, five wrong answers
+
+Reading `PackageLib`'s uncovered lines and asking "can a Lua script reach this?"
+led to `searcher_C`'s fallback and, from there, to a module name that collides
+with a directory. That turned out to be **one rule mis-modelled in five places**:
+
+POSIX lets `open(dir, O_RDONLY)` succeed. `fopen(dir, "r")` therefore succeeds;
+`fopen(dir, "w")` gives `EISDIR`; and the first `fgetc` / `fread` fails with
+`EISDIR`. The JVM refuses to open a directory at all, so this implementation got
+all five entry points wrong in one consistent way:
+
+| | reference | before |
+| --- | --- | --- |
+| `loadfile(dir)` | `nil, "cannot read <p>: Is a directory"` | `nil, "cannot open <p>: Input/output error"` |
+| `io.open(dir, "r")` | a file handle | `nil, "<p>: No such file or directory", 2` |
+| `io.open(dir, "w")` | `nil, "<p>: Is a directory", 21` | `nil, "<p>: No such file or directory", 2` |
+| `package.searchpath` | finds it (returns the path) | `nil, "no file '<p>'"` |
+| `require(name)` | `error loading module … cannot read …` | `module '…' not found` |
+
+The fix is one idea applied at four sites: `openInto` lets a read-only open of a
+directory through (and reports `EISDIR` for anything writable), `LuaFile.getc` /
+`read` fail with 21, `seek` / `tell` treat it as a zero-length file (a directory
+descriptor *is* seekable — `f:seek("set", 5)` returns 5, and `f:seek("set", -1)`
+is still `EINVAL`), `PackageLib.readable` accepts directories, and `loadfile` /
+`searcher_Lua` take the `cannot read` branch instead of `cannot open`.
+
+18 lines, byte-identical after the fix. Two things about how this was found are
+worth more than the bug:
+
+* The README previously said directories were "fine and must not be fixed" —
+  written from reading `lauxlib.c`, not from running the reference binary. It was
+  wrong. Measure, then write.
+* The same sentence in the *code* comment (`BaseLib`) had asserted the behaviour
+  was already correct. A comment agreeing with the code is not evidence.
+
 ### What is still missing
 
 Nothing in the language or the ten standard libraries, and every upstream file
 
@@ -184,7 +184,7 @@ Lua 参考实现的解析器是手写递归下降。直接搬过来，就去掉
 `utf8`、`vararg`、`verybig` 等）与真实 `lua5.4` 的输出**逐字节一致**；
 `cstack` / `gc` / `literals` / `locals` / `constructs` 五个因为打印的是随实现或
 随随机数而变的东西，只断言「跑完并打印 `OK`」——理由逐个列在 *阶段 10* 一节里。
-全量 848 个用例绿，JaCoCo 行覆盖 0.90（门禁 0.89）。（上游套件这道闸门要
+全量 850 个用例绿，JaCoCo 行覆盖 0.90（门禁 0.89）。（上游套件这道闸门要
 `LUA54_TESTS` 或 `target/lua54-tests`；没有用例目录时<b>整类自动跳过</b>，
 所以那种机器上「绿」其实比看起来少 25 个用例。）
 
@@ -1464,9 +1464,14 @@ C 靠 `luaD_rawrunprotected` 末尾的 `L->nCcalls = oldnCcalls`（在 `pcall`
 `errnoOf` 的兜底分支就成了 `EIO`(5)。往 EOF **之后**定位是合法的（返回新位置，
 不报错）—— 修这条时别顺手一起拦了。
 
-两处刻意不测：`fopen` 一个**目录**在 macOS 与 glibc 上都成功、但读的行为不同，
-而 JVM 压根不允许把目录当流打开；`print` 写的是 C 层的 `stdout`，不受
-`io.output` 切换影响 —— 假设它会跟着变的脚本，两边会各自给出一个错的答案。
+一处刻意不测：`print` 写的是 C 层的 `stdout`，不受 `io.output` 切换影响 ——
+假设它会跟着变的脚本，两边会各自给出一个错的答案。
+
+`fopen` 一个**目录**原本也写在这一节里，那是错的：它是一条完整的 POSIX 规则
+（`open(dir, O_RDONLY)` 成功、`O_WRONLY` 给 `EISDIR`、第一次读失败于 `EISDIR`），
+macOS 与 glibc 一样，只是 JVM 不愿意建模。现在建模了，见下文 *目录那个 bug*。
+真正不能比的只有目录上的 `seek("end")`：给的是目录自身的大小（本机 64），
+那是文件系统的事实，不是 Lua 的事实。
 
 #### `os.time` 那半边：`lua_tointegerx` 是带字符串转换的
 
@@ -1632,8 +1637,12 @@ const char *luaT_objtypename (lua_State *L, const TValue *o) {
 `fopen("")` 给 `ENOENT`，报 `cannot open : No such file or directory`；Java 把
 空路径解析成当前目录、失败在读，给 `Is a directory`，我们于是报成了
 `Input/output error`。空路径是唯一一处，按 C 的判据单独取 `ENOENT`。
-**目录本身不用改、也不该改**：`loadfile("/tmp")` 在 C 里 `fopen` 是**成功**的，
-失败在读，走的是另一条分支 —— `cannot read /tmp: Is a directory`。
+目录原本在同一句里被断言成「不用改、也不该改」—— 而这句是错的，值得留着当教训：
+它是**读 lauxlib.c 读出来的，不是跑参考实现跑出来的**。C 里 `loadfile("/tmp")`
+确实是 `fopen` 成功、失败在读，但本实现报的是
+`cannot open /tmp: Input/output error`（Java 的 `Files.readAllBytes` 在开就抛了），
+也就是<b>另一条分支</b>。量过之后，一句错话变成五个门口的真 bug，
+见下文 *目录那个 bug*。
 
 #### 一片铺下来是干净的：`load` 的读取器契约（54 行）
 
@@ -1945,6 +1954,36 @@ nil / false / true / 数字 / 无返回 / 多值（只取第一个）、模块
 39 行全逐字节一致 —— 也就是说这些分支<b>本来就是对的，只是没人跑过</b>。
 它们的价值在回归：谁改了 `read("n")` 的前缀判断或 wbuf 的阈值，这里立刻红。
 
+#### 目录那个 bug：一条 POSIX 规则，五处全错
+
+读 PackageLib 的未覆盖行、逐条问「Lua 能不能走到」，摸到 `searcher_C` 的兜底
+分支，再摸到「模块名撞上目录」这件事 —— 结果是**一条规则没建模，五个门口全错**：
+
+POSIX 允许 `open(dir, O_RDONLY)` 成功。于是 `fopen(dir,"r")` 成功、
+`fopen(dir,"w")` 给 `EISDIR`、第一次 `fgetc`/`fread` 失败于 `EISDIR`。
+JVM 根本不让打开目录，于是本实现以同一种方式在五处同时错：
+
+| | 参考 | 修之前 |
+| --- | --- | --- |
+| `loadfile(dir)` | `nil, "cannot read <p>: Is a directory"` | `nil, "cannot open <p>: Input/output error"` |
+| `io.open(dir,"r")` | file 句柄 | `nil, "<p>: No such file or directory", 2` |
+| `io.open(dir,"w")` | `nil, "<p>: Is a directory", 21` | `nil, "<p>: No such file or directory", 2` |
+| `package.searchpath` | 找到（返回路径） | `nil, "no file '<p>'"` |
+| `require(name)` | `error loading module … cannot read …` | `module '…' not found` |
+
+修法是同一个念头落在四处：`openInto` 放行只读的目录打开（要写就报 EISDIR）、
+`LuaFile.getc`/`read` 报 21、`seek`/`tell` 按零长文件算（目录 fd **是**可定位的：
+`f:seek("set",5)` 给 5，`f:seek("set",-1)` 仍然是 EINVAL）、
+`PackageLib.readable` 认目录、`loadfile` 与 `searcher_Lua` 改走 `cannot read`
+那条分支。
+
+修完 18 行逐字节一致。怎么发现的，比这个 bug 本身更值得记：
+
+* README 之前写着目录「没问题、不要修」—— 那是<b>读 lauxlib.c 读出来的，不是
+  跑参考实现跑出来的</b>，而且它是错的。先量，再写。
+* 代码注释（`BaseLib`）里那句同样断言了「目录不用改」。
+  **注释跟代码保持一致不是证据。**
+
 ### 还没补上的
 
 语言与十个标准库本身没有缺项，上游套件里能逐字节比的那些也都比过了。剩下的是
 
@@ -1059,14 +1059,25 @@ private static int loadfileFn(LuaState L) {
              * {@code ENOENT}（实测 {@code loadfile("")} 报
              * {@code cannot open : No such file or directory}），而 Java 把空路径
              * 解析成当前目录、读的时候给 {@code Is a directory}。
-             * 目录本身不用改：{@code loadfile("/tmp")} 在 C 里 fopen 是<b>成功</b>的、
-             * 失败在读，走的就是 {@code cannot read ...: Is a directory} 那条分支。
+             * <p>
+             * 目录走的是<b>另一条</b>分支，之前这里是错的：{@code loadfile("/tmp")}
+             * 在 C 里 fopen <b>成功</b>、失败在读，{@code luaL_loadfilex} 的
+             * {@code ferror} 于是为真，报的是
+             * {@code cannot read /tmp: Is a directory} —— 不是
+             * {@code cannot open ...: Input/output error}。实测（参考二进制）：
+             * <pre>
+             * loadfile(dir) -> nil, "cannot read /tmp/fkdir/adir.lua: Is a directory"
+             * </pre>
              */
-            int en = path.isEmpty() ? 2 : LuaAux.errnoOf(
-                    (e instanceof java.io.IOException) ? (java.io.IOException) e : null);
+            boolean isDir = !path.isEmpty() && new java.io.File(path).isDirectory();
+            int en = path.isEmpty() ? 2
+                    : isDir ? 21
+                    : LuaAux.errnoOf((e instanceof java.io.IOException)
+                            ? (java.io.IOException) e : null);
             LuaAux.pushFail(L);
             L.push(LuaValue.ofString(LuaString.latin1(
-                    "cannot open " + path + ": " + LuaAux.strError(en))));
+                    (isDir ? "cannot read " : "cannot open ") + path + ": "
+                            + LuaAux.strError(en))));
             return 2;
         }
         /*
 
@@ -147,6 +147,24 @@ static final class LuaFile {
         boolean writable;
         boolean append;
 
+        /**
+         * 打开的是<b>目录</b>。
+         * <p>
+         * POSIX 的 {@code fopen(dir, "r")} 是<b>成功</b>的（{@code open(dir, O_RDONLY)}
+         * 允许），失败发生在第一次 {@code fgetc} / {@code fread} 上，errno 是
+         * {@code EISDIR}(21)。实测（参考二进制）：
+         * <pre>
+         * io.open(dir, "r")   -> file 句柄；f:read("l") -> nil, "Is a directory", 21
+         * io.open(dir, "w")   -> nil, "&lt;path&gt;: Is a directory", 21
+         * </pre>
+         * Java 的 {@code RandomAccessFile} 在目录上是开都开不了的，所以这里
+         * 单独记一个标记：打开时放行只读，读写一律报 21。
+         */
+        boolean dir;
+
+        /** 目录被当零长文件看待时的虚拟位置 —— 目录 fd 上的 {@code lseek} 是允许的 */
+        long dirPos;
+
         /** {@code ungetc} 的回退位；{@code -1} 表示空 */
         int pushback = -1;
 
@@ -215,6 +233,11 @@ int getc() {
                 errno = 9; // EBADF
                 return -1;
             }
+            if (dir) {
+                err = true;
+                errno = 21; // EISDIR：目录读不出来，但打开是成功的
+                return -1;
+            }
             flushW(); // C 要求输出与输入之间必须有 fflush 或定位操作
             try {
                 return raf != null ? raf.read() : inStream().read();
@@ -246,6 +269,11 @@ int read(byte[] b, int off, int len) {
                 errno = 9; // EBADF
                 return done;
             }
+            if (dir) {
+                err = true;
+                errno = 21; // EISDIR
+                return done;
+            }
             flushW();
             try {
                 int r = (raf != null) ? raf.read(b, off + done, len - done)
@@ -313,6 +341,22 @@ void write(byte[] b, int off, int len) {
 
         /** {@code l_fseek}：成功返回新位置，-1 表示失败（管道会失败） */
         long seek(long offset, int whence) {
+            if (dir) {
+                /*
+                 * 目录 fd 上的 lseek 是允许的，位置照算；长度按 0 看。
+                 * 真实目录的 SEEK_END 给出的是目录自身的大小（本机 64），
+                 * 那是文件系统定的、不比 —— 见用例 javadoc。
+                 */
+                long base = (whence == 1) ? dirPos : 0; // 仅 SEEK_CUR 从当前位置起算
+                long pos = base + offset;
+                if (pos < 0) {
+                    err = true;
+                    errno = 22; // EINVAL
+                    return -1;
+                }
+                dirPos = pos;
+                return pos;
+            }
             if (raf == null) {
                 err = true;
                 errno = 29; // ESPIPE
@@ -358,6 +402,9 @@ long seek(long offset, int whence) {
 
         /** {@code l_ftell} */
         long tell() {
+            if (dir) {
+                return dirPos; // 目录 fd 上的 ftell 是允许的
+            }
             if (raf == null) {
                 err = true;
                 errno = 29; // ESPIPE
@@ -587,6 +634,20 @@ private static boolean openInto(LuaFile f, String fname, String mode) {
         f.readable = (base == 'r') || plus;
         f.writable = (base != 'r') || plus;
         f.append = (base == 'a');
+        /*
+         * 目录：C 的 fopen 在只读模式上是开得开的（open(dir, O_RDONLY) 允许），
+         * 要写才给 EISDIR。Java 这边 RandomAccessFile 两种模式都开不了，
+         * 所以先判目录再分模式 —— 否则写目录报的是 ENOENT 而不是 EISDIR。
+         */
+        if (new java.io.File(fname).isDirectory()) {
+            if (f.writable) {
+                f.err = true;
+                f.errno = 21; // EISDIR
+                return false;
+            }
+            f.dir = true;
+            return true;
+        }
         try {
             f.raf = new RandomAccessFile(fname, f.writable ? "rw" : "r");
             if (base == 'w') {
 
@@ -447,6 +447,8 @@ public static String strError(int en) {
             return "Bad file descriptor";
         case 22: // EINVAL
             return "Invalid argument";
+        case 21: // EISDIR
+            return "Is a directory";
         case 29: // ESPIPE
             return "Illegal seek";
         default:
 
@@ -218,8 +218,18 @@ private static List<String> splitPath(String path) {
         return out;
     }
 
-    /** {@code readable}：能打开读就算数 */
+    /**
+     * {@code readable}：能打开读就算数。
+     * <p>
+     * C 用的是 {@code fopen(filename, "r")}，而它在<b>目录</b>上是成功的 ——
+     * 于是 {@code searchpath} 会把目录当成找到的文件返回，后面的
+     * {@code luaL_loadfilex} 才在读的时候报 {@code cannot read ...: Is a directory}。
+     * Java 的 {@code RandomAccessFile} 开不了目录，所以这里得先认下目录。
+     */
     private static boolean readable(String filename) {
+        if (new java.io.File(filename).isDirectory()) {
+            return true;
+        }
         try (java.io.RandomAccessFile f = new java.io.RandomAccessFile(filename, "r")) {
             return true;
         } catch (IOException e) {
@@ -371,6 +381,19 @@ private static int searcherLua(LuaState L) {
             return 1; // 消息已压栈
         }
         try {
+            /*
+             * 与 {@code BaseLib.loadfile} 的目录分支是同一件事的两处：
+             * 模块文件是目录时，C 的 fopen 成功、读才失败，
+             * {@code luaL_loadfilex} 报的是
+             * {@code cannot read <filename>: Is a directory}。
+             * 实测（参考二进制）：
+             * {@code require("adir")} -> "error loading module 'adir' from file
+             * '<p>':\n\tcannot read <p>: Is a directory"。
+             */
+            if (new java.io.File(filename).isDirectory()) {
+                throw new java.io.IOException("cannot read " + filename + ": "
+                        + LuaAux.strError(21));
+            }
             byte[] src = Files.readAllBytes(Paths.get(filename));
             /*
              * luaL_loadfilex 的 chunk 名是 "@" + 文件名。不带这个前缀，