Commit 8c0c5e6
committed
Revert HasSuccessfulAccess to use retVal==0 check instead of OKReturnStatus
The kilo-code-bot suggested changing the HasSuccessfulAccess condition from
`e.retVal == 0 || p.SyscallType() == OpenFileType` to `p.OKReturnStatus(e.retVal)`,
arguing that the former incorrectly treated all OpenFileType syscalls as successful.
However, the original expression was correct:
- For OpenFileType (open, openat, readlink): the outer condition on line 276-278
already filters to successful calls via `p.OKReturnStatus(e.retVal)`, which
requires fd >= 0. The `|| p.SyscallType() == OpenFileType` clause is redundant,
not wrong -- it simply ensures HasSuccessfulAccess=true for events that already
passed the success filter.
- For CheckFileType (stat, access, lstat): `e.retVal == 0` correctly marks only
files that actually exist on disk. The replacement `p.OKReturnStatus(e.retVal)`
also accepts ENOENT (-2) and ENOTDIR (-20), causing non-existent "ghost" paths
to be marked as HasSuccessfulAccess=true.
This broke the namespace package fix (da8eb2c): when Python probes for
__init__.cpython-311.so, __init__.so, __init__.py in a directory that has none
of them (namespace package), those ENOENT stat results created ghost children
with HasSuccessfulAccess=true. The FileActivity() radix tree walk then marked
the parent directory as IsSubdir and excluded it from the slim image. Since the
ghost children don't exist on disk, neither the directory nor its contents were
preserved, causing libraries to go missing.1 parent 27c344b commit 8c0c5e6
1 file changed
+2
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
286 | 286 | | |
287 | 287 | | |
288 | 288 | | |
289 | | - | |
| 289 | + | |
290 | 290 | | |
291 | 291 | | |
292 | 292 | | |
| |||
300 | 300 | | |
301 | 301 | | |
302 | 302 | | |
303 | | - | |
| 303 | + | |
304 | 304 | | |
305 | 305 | | |
306 | 306 | | |
| |||
0 commit comments