cyxer000 110567472d edit: a config that is a hard link stays one when magpie saves or clears it (#328) ...

* edit: a config that is a hard link stays one when magpie saves or clears it — WriteAtomic renamed a temp file over the path even when the file had other names, so a models.yml that Orca keeps hard-linked into its overlay split in two: omp's name got the new text, the overlay kept the old one, and each later write drifted further; clearing an instructions file unlinked only magpie's name and left the old text under the others. Now a regular file with more than one link (st_nlink on unix, NumberOfLinks from GetFileInformationByHandle on Windows, one elsewhere) is written in place: the new text first goes to a temp file beside it and is synced, then is written over the file, cut to length and synced, and the temp file goes; a crash part way leaves the whole new text beside it, and a failed write keeps it and names it in the error. Mode, owner and every name stay. Remove empties such a file instead of unlinking one name, as it already did for a symlink, and a failed edit rolled back by Atomically goes back in place too. A file with one link is still replaced by rename, atomically, as before.

* edit: a read-only hard-linked config is still written, and temp files a crashed write left beside a config go at its next write

Review follow-up on #328:

- A hard-linked file that can't be opened for writing (0444 on unix,
  read-only on Windows) fell over with "permission denied" where main's
  rename replaced it. WriteAtomic now opens it first and, on
  fs.ErrPermission, falls back to temp file + rename as before, which
  splits that name from the others as main always did. On Windows main
  couldn't rename over a read-only file either, so nothing changes there.
- writeInPlace says why it writes over and then cuts to length: a reader
  can briefly see the new text with the old one's tail, but emptying first
  would show an empty or half file instead, which a tool may load as a
  config with nothing set; a mangled one fails to parse.
- writeInPlace names the trade with hard-link backups (rsnapshot, cp -al,
  rsync --link-dest): they change with the file, as with vim's
  backupcopy=auto.
- Remove says that emptying every name is meant: with AGENTS.md and
  CLAUDE.md one file, clearing one empties both, as #323 does for a
  symlink's target, since deleting one name would leave the text magpie is
  taking back under the other.
- After a write goes through, both paths remove .<name>.<digits>.tmp
  beside the file older than ten minutes: the file then holds newer text
  than any of them, a fresh one may be another write's still under way,
  and the digits keep other files' temps (.models.yml.bak.1.tmp) out.

2026-09-30 23:36:01 +08:00

..

del_test.go

dial: one dial for every coding agent's model

2026-09-22 21:47:29 +08:00

edit_test.go

dial: one dial for every coding agent's model

2026-09-22 21:47:29 +08:00

env.go

dial: one dial for every coding agent's model

2026-09-22 21:47:29 +08:00

file.go

edit: a config that is a hard link stays one when magpie saves or clears it (#328)

2026-09-30 23:36:01 +08:00

hardlink_other.go

edit: a config that is a hard link stays one when magpie saves or clears it (#328)

2026-09-30 23:36:01 +08:00

hardlink_test.go

edit: a config that is a hard link stays one when magpie saves or clears it (#328)

2026-09-30 23:36:01 +08:00

hardlink_windows.go

edit: a config that is a hard link stays one when magpie saves or clears it (#328)

2026-09-30 23:36:01 +08:00

json.go

dial: one dial for every coding agent's model

2026-09-22 21:47:29 +08:00

symlink_test.go

edit: a config kept as a symlink stays one when magpie saves or clears it (#323, jigaowan) — WriteAtomic wrote a temp file beside the path and renamed it over it, so a linked library.json, instructions.md, CLAUDE.md, settings.json or config.toml became a file of its own and the dotfiles target kept its old text; clearing instructions.md removed the link. Now a write goes to the file at the end of the links (the one it names when nothing is there yet, an error for a loop of links), keeping its mode, and clearing a linked file empties its target and keeps the link (Pi's migrated mcp.json stays as {}); a plain file is removed as before. Sign-ins and the Kiro/StepFun files magpie writes privately follow links the same way, and a failed edit rolled back deletes only what it made behind a link to nothing. TestWriteAtomicFollowsSymlink, TestRemoveKeepsSymlink, TestAtomicallyKeepsSymlink, TestLinkedFilesStayLinked and TestPrivateWritesKeepSymlink fail without the change. go vet, go build -tags nogui (darwin, GOOS=linux), GOOS=windows go build, go test -tags nogui ./... pass.

2026-09-30 20:21:24 +08:00

text.go

toml: Codex's config.toml with a multi-line array (notify = [ … ]) is edited right, and an edit that fails leaves every file as it was (#253 kerwinliu00001: "edited TOML is invalid: line 2, column 1: incomplete number", config.toml left with model_provider gone and [model_providers.magpie] added but no model) — the top-level key edits (GetTOMLTop, SetTOMLTop, DelTOMLTop) went line by line with regexes: a new key went after the last line that looked like key = …, which for notify = [ was inside the array; key = value lines inside a multi-line string were read as keys and a line starting with [ as a table; replacing or deleting a multi-line value touched only its first line. They now locate the top-level keys with the TOML parser, as the table edits already did, each with its value's whole range however many lines it takes (parseTOMLFile, the unnamed root table beside the tables); SetTOMLTop finds all its keys in the file as read and writes once. A file the parser refuses is still read line by line, so a broken config keeps showing its model, and writes to it are refused untouched. And a pick is several writes (Codex: drop model_provider, add magpie's provider table, set openai_base_url and model), each checked, so one failing left the earlier ones on disk: edit.Atomically(fn, paths…) puts each file back to its bytes and mode, or removes one it created, when fn fails, and every field set and Sync of Codex (config.toml and magpie-models.json, so Codex in WSL too), Kimi and Grok goes through it, as do Codex's MCP server writes (putCodex, delCodex). Tested in temp dirs and a temp HOME: the reporter's file read, set and deleted directly and through Codex's model field (signed in, with model_provider and model above the array, with magpie as the provider), the array's text kept and the TOML valid, and back to a Codex model; nested arrays, trailing commas, comments in arrays, [x] and a = b in strings, an inline table in an array; """ and ''' strings holding model = … and [table] lines not read as keys, new keys after their closing quotes, one deleted whole; a forced failure of Codex's last write leaving config.toml byte-identical; TestAtomically. They fail on main (the Codex ones with the reporter's error). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against a real ~/.codex, in WSL or in the GUI; multi-line inline tables (TOML 1.1) are refused by the parser and so left untouched with an error.

2026-09-30 09:31:59 +08:00

toml_multiline_test.go

toml: Codex's config.toml with a multi-line array (notify = [ … ]) is edited right, and an edit that fails leaves every file as it was (#253 kerwinliu00001: "edited TOML is invalid: line 2, column 1: incomplete number", config.toml left with model_provider gone and [model_providers.magpie] added but no model) — the top-level key edits (GetTOMLTop, SetTOMLTop, DelTOMLTop) went line by line with regexes: a new key went after the last line that looked like key = …, which for notify = [ was inside the array; key = value lines inside a multi-line string were read as keys and a line starting with [ as a table; replacing or deleting a multi-line value touched only its first line. They now locate the top-level keys with the TOML parser, as the table edits already did, each with its value's whole range however many lines it takes (parseTOMLFile, the unnamed root table beside the tables); SetTOMLTop finds all its keys in the file as read and writes once. A file the parser refuses is still read line by line, so a broken config keeps showing its model, and writes to it are refused untouched. And a pick is several writes (Codex: drop model_provider, add magpie's provider table, set openai_base_url and model), each checked, so one failing left the earlier ones on disk: edit.Atomically(fn, paths…) puts each file back to its bytes and mode, or removes one it created, when fn fails, and every field set and Sync of Codex (config.toml and magpie-models.json, so Codex in WSL too), Kimi and Grok goes through it, as do Codex's MCP server writes (putCodex, delCodex). Tested in temp dirs and a temp HOME: the reporter's file read, set and deleted directly and through Codex's model field (signed in, with model_provider and model above the array, with magpie as the provider), the array's text kept and the TOML valid, and back to a Codex model; nested arrays, trailing commas, comments in arrays, [x] and a = b in strings, an inline table in an array; """ and ''' strings holding model = … and [table] lines not read as keys, new keys after their closing quotes, one deleted whole; a forced failure of Codex's last write leaving config.toml byte-identical; TestAtomically. They fail on main (the Codex ones with the reporter's error). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against a real ~/.codex, in WSL or in the GUI; multi-line inline tables (TOML 1.1) are refused by the parser and so left untouched with an error.

2026-09-30 09:31:59 +08:00

toml_test.go

edit: a table's name is the parser's own key path, so [ a . b ] is the table a.b — space or tab around the dots of a header (both valid TOML) is not part of the name; a provider table a user wrote that way is reused in place, edited and taken away again as if magpie had written it, where before it was invisible and magpie appended a duplicate, refused as invalid TOML

2026-09-26 21:12:32 +08:00

toml_write_test.go

toml: Codex's config.toml with a multi-line array (notify = [ … ]) is edited right, and an edit that fails leaves every file as it was (#253 kerwinliu00001: "edited TOML is invalid: line 2, column 1: incomplete number", config.toml left with model_provider gone and [model_providers.magpie] added but no model) — the top-level key edits (GetTOMLTop, SetTOMLTop, DelTOMLTop) went line by line with regexes: a new key went after the last line that looked like key = …, which for notify = [ was inside the array; key = value lines inside a multi-line string were read as keys and a line starting with [ as a table; replacing or deleting a multi-line value touched only its first line. They now locate the top-level keys with the TOML parser, as the table edits already did, each with its value's whole range however many lines it takes (parseTOMLFile, the unnamed root table beside the tables); SetTOMLTop finds all its keys in the file as read and writes once. A file the parser refuses is still read line by line, so a broken config keeps showing its model, and writes to it are refused untouched. And a pick is several writes (Codex: drop model_provider, add magpie's provider table, set openai_base_url and model), each checked, so one failing left the earlier ones on disk: edit.Atomically(fn, paths…) puts each file back to its bytes and mode, or removes one it created, when fn fails, and every field set and Sync of Codex (config.toml and magpie-models.json, so Codex in WSL too), Kimi and Grok goes through it, as do Codex's MCP server writes (putCodex, delCodex). Tested in temp dirs and a temp HOME: the reporter's file read, set and deleted directly and through Codex's model field (signed in, with model_provider and model above the array, with magpie as the provider), the array's text kept and the TOML valid, and back to a Codex model; nested arrays, trailing commas, comments in arrays, [x] and a = b in strings, an inline table in an array; """ and ''' strings holding model = … and [table] lines not read as keys, new keys after their closing quotes, one deleted whole; a forced failure of Codex's last write leaving config.toml byte-identical; TestAtomically. They fail on main (the Codex ones with the reporter's error). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against a real ~/.codex, in WSL or in the GUI; multi-line inline tables (TOML 1.1) are refused by the parser and so left untouched with an error.

2026-09-30 09:31:59 +08:00

toml.go

toml: Codex's config.toml with a multi-line array (notify = [ … ]) is edited right, and an edit that fails leaves every file as it was (#253 kerwinliu00001: "edited TOML is invalid: line 2, column 1: incomplete number", config.toml left with model_provider gone and [model_providers.magpie] added but no model) — the top-level key edits (GetTOMLTop, SetTOMLTop, DelTOMLTop) went line by line with regexes: a new key went after the last line that looked like key = …, which for notify = [ was inside the array; key = value lines inside a multi-line string were read as keys and a line starting with [ as a table; replacing or deleting a multi-line value touched only its first line. They now locate the top-level keys with the TOML parser, as the table edits already did, each with its value's whole range however many lines it takes (parseTOMLFile, the unnamed root table beside the tables); SetTOMLTop finds all its keys in the file as read and writes once. A file the parser refuses is still read line by line, so a broken config keeps showing its model, and writes to it are refused untouched. And a pick is several writes (Codex: drop model_provider, add magpie's provider table, set openai_base_url and model), each checked, so one failing left the earlier ones on disk: edit.Atomically(fn, paths…) puts each file back to its bytes and mode, or removes one it created, when fn fails, and every field set and Sync of Codex (config.toml and magpie-models.json, so Codex in WSL too), Kimi and Grok goes through it, as do Codex's MCP server writes (putCodex, delCodex). Tested in temp dirs and a temp HOME: the reporter's file read, set and deleted directly and through Codex's model field (signed in, with model_provider and model above the array, with magpie as the provider), the array's text kept and the TOML valid, and back to a Codex model; nested arrays, trailing commas, comments in arrays, [x] and a = b in strings, an inline table in an array; """ and ''' strings holding model = … and [table] lines not read as keys, new keys after their closing quotes, one deleted whole; a forced failure of Codex's last write leaving config.toml byte-identical; TestAtomically. They fail on main (the Codex ones with the reporter's error). go vet ./internal/..., go build -tags nogui (and GOOS=linux, GOOS=windows) and go test -tags nogui ./... pass. Not tried against a real ~/.codex, in WSL or in the GUI; multi-line inline tables (TOML 1.1) are refused by the parser and so left untouched with an error.

2026-09-30 09:31:59 +08:00

yaml_test.go

agent: omp (oh-my-pi) — its model picked in magpie like any agent's; a model through magpie adds magpie as a keyless provider in ~/.omp/agent/models.yml with the catalog as its models, and sets config.yml's modelRoles.default to magpie/<provider>/<model>; its other roles and the rest of both files stay as they are, comments too, and default takes magpie's entry out unless another role still uses it (#34)

2026-09-24 22:36:15 +08:00

yaml.go

agents: omp keeps magpie while a fallback chain or another role is on it, and a provider renamed takes those along (#340)

2026-09-30 22:58:42 +08:00