3182da3965
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:
- D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
invisible until moved across by hand.
- Development happens from Windows and from Linux, and each looks in a
different place for the same checkout.
Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.
The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
---
|
|
name: schunix-linux-open-flags
|
|
description: "include/fcntl.h must hold Linux's open-flag values — the userland is all Linux-ABI, and a mismatch silently corrupts files"
|
|
metadata:
|
|
node_type: memory
|
|
type: project
|
|
originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
|
|
modified: 2026-08-03T13:59:19.392Z
|
|
---
|
|
|
|
**`include/fcntl.h` holds Linux x86-64 open-flag values, and must keep holding
|
|
them.** Every program in the userland is built against a libc that sends Linux
|
|
values; the kernel reads them with these constants. Do not "tidy" them into a
|
|
neat sequence — they are an external interface.
|
|
|
|
They disagreed until 2026-08-03, and the symptoms looked like filesystem
|
|
corruption rather than a header mistake:
|
|
|
|
- Linux `O_APPEND` (0x400) landed on Schunix's `O_TRUNC`, so **`cmd >> file`
|
|
truncated** the file it was supposed to extend.
|
|
- Linux `O_TRUNC` (0x200) landed on `O_CREATE`, so **`cmd > file` did not
|
|
truncate** and left whatever was past the new end in place.
|
|
|
|
Found by making `tools/bootcheck.ps1` do ordinary shell work — write a file,
|
|
append to it, `wc -c` the result — instead of only booting to a prompt. The
|
|
byte count was the only thing that said which failure had happened. See
|
|
[[schunix-verify-by-driving-shell]].
|
|
|
|
Two related traps fixed at the same time, both worth re-checking after any
|
|
syscall work:
|
|
|
|
- `sys_openat` silently dropped `O_TRUNC` and `O_APPEND` while `sys_open`
|
|
honoured both, so the same redirection behaved differently depending on which
|
|
entry point libc called. **Any flag handled in one must be handled in both.**
|
|
- `rmdir` was `NO_LINUX` in `kernel/sys/table.inc`, so every Linux-ABI program
|
|
got ENOSYS. A syscall with no Linux number is unreachable from userland —
|
|
see [[schunix-syscall-single-table]].
|