nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schunix-linux-open-flags.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
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.
2026-08-09 14:27:22 +02:00

1.7 KiB
Raw Blame History

name description metadata
schunix-linux-open-flags include/fcntl.h must hold Linux's open-flag values — the userland is all Linux-ABI, and a mismatch silently corrupts files
node_type type originSessionId modified
memory project a665e14b-86bd-4b41-a228-51377f3e9225 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.