[nissa-seru]

On a disk that folds case, as macOS's does by default, a path to a file that isn't on disk yet now takes the spelling of the workspace's draft it equals in lower case, so a second draft spelled in another case is the first one. And a path that names a workspace entry exactly keeps that spelling, so an entry that disk lists in another spelling is read, synced and deleted by its own path again, and a file deleted in the workspace while disk keeps its copy is still reached by its own path. The second part mends something #525 broke: since #525, such an entry was out of reach of every tool, delete of its path deleted the other file, and a file deleted in the workspace came back on a read.

Problem

Probed on main c0155d39 on Linux, with Node 24, on ext4 and on the FUSE filesystem described under Tests, which folds case and NFC against NFD. The mount's writes stayed drafts until materialized, as by default (autoMaterialize: false).

• Two file drafts that differ only in case, src/New.txt ("first") and src/NEW.txt ("second"), were two entries for one file.

  • A materialize wrote NEW.txt and skipped New.txt: "not written: something appeared at this path since it was checked". The next materialize called src/New.txt a conflict.
  • A forced materialize wrote both, the second over the first. The next sync kept the later bytes under NEW.txt and deleted New.txt, so "second" was gone.

• Since fix(workspace): take a path as disk spells it on a disk that folds names #525, the skipped draft couldn't be reached by its own path. Every tool took the path as disk spells it, so it reached NEW.txt:

  • read work/src/New.txt answered with NEW.txt's bytes;
  • sync and a forced materialize of that path, the remedies the conflict names, acted on NEW.txt and left the draft as it was;
  • delete work/src/New.txt deleted NEW.txt, and materialize with applyDeletions then took it off disk.

  At 0a7fd161, main just before fix(workspace): take a path as disk spells it on a disk that folds names #525, the same calls read, synced and deleted the draft itself.

• A file deleted in the workspace, with its disk copy kept, was out of reach of its own path too, once disk listed it in another case. Greptile found it on 5da80f9a, an earlier head of this change, which kept an entry's spelling but not a deletion's. Such a file has no entry, only the deletion, so its path took disk's spelling. There, a read of the path took the file in again, and a materialize of the path with applyDeletions missed the deletion. Where disk had changed the file since the deletion, the read took it in rather than answering that it's in conflict. With main b82ba630d's sources, the two tests this change adds for it fail too. In the first, delete of the path answers with disk's spelling, as above. In the second, where the file is deleted before disk changes it, the read takes it in again. Both pass at 0a7fd161, on the folding disk.

• Two directory drafts, Docs/a.txt and DOCS/b.txt, became one disk directory, DOCS/. The next sync announced deleted work/Docs/a.txt and created work/DOCS/a.txt. Nothing was lost.

• A file draft and a directory draft of one name, src/Item and src/ITEM/x.txt: the directory was written, and the file draft was skipped and stranded, as above.

On ext4 each pair was two files, as it should be.

Changes

• diskSpelling (src/modules/workspace/observe.ts) takes what the workspace holds of the mount (WorkspaceEntries), which parsePath passes it, so every tool's path goes through it:
  • a path the workspace holds an entry at exactly, or records an intent at, such as a deletion disk hasn't been given yet or a conflict, keeps its spelling whole, and a last segment where the workspace holds either at exactly that path keeps its spelling once the directories have taken disk's;
  • disk's spelling comes next, as before;
  • a segment disk has nothing for takes the name of an entry it equals in simple case folding, letter by letter (lowered, entryName), where the directory reached folds case;
  • none of this applies where disk's spelling puts the path in a nested mount's directory: there the path keeps disk's spelling.
• entriesOf (src/modules/workspace/index.ts) gives it the mount's entries on the current branch, the paths it records an intent at there, and which nested mount's directory holds a path (holder), by holderOf, the nested-mount checks' own reading of a path.
• foldsCase tells whether a directory folds case without writing to it. start reads it for each mount's root where disk has it, at the real root readNesting places, before it sets anything. readNesting now returns those real roots beside the nesting.
• listedName also returns whether it found the segment's file on disk, through a variant or, for a segment with no variant, as given, and what looking the segment up with its case flipped showed of the directory.

What each part is for

• An entry's own spelling first. An entry and the file disk lists can be two names for one file: a draft beside a file made on disk in another case before the draft was materialized, a draft whose directory disk comes to list in another case, or two calls in flight at once, each naming a new file in a different case. Taking disk's spelling first sends every path to the file disk lists and leaves the entry out of reach, which is what fix(workspace): take a path as disk spells it on a disk that folds names #525 did. With the entry's own spelling first, a read, delete and the conflict's remedies act on the entry the path names. Whether the whole path names an entry is read before the walk awaits disk, and where it doesn't, the last segment is checked again once the directories have taken disk's spelling. A path the workspace records an intent at counts as an entry here. A file deleted in the workspace while disk keeps its copy has no entry, only that intent. Were the intent not counted, a path to the file would take disk's spelling once disk listed the file in another case, so a read would take the deleted file in again, and a materialize of its path with applyDeletions would miss the deletion. A conflict is settled by a sync of its own path the same way.
• An entry's name where disk has nothing. On a disk that folds case, a draft's path names the file its entry will be. Taking an entry's spelling makes a second draft in another case the same entry, as disk will once it's written, and lets a read in another case find the draft. A directory segment works the same way, so directory drafts in two spellings are one directory.
• An entry's spelling takes no path out of a nested mount's directory. A nested mount's directory is the nested mount's, and the checks that refuse a path there compare spellings exactly, knowing the configured one and disk's. An outer entry in another spelling, kept from before the nested mount was configured or before its directory was on disk, could otherwise give a path a spelling they don't know: a stale draft in Proj/ would respell proj/inner/x.txt, which main refuses as a nested mount's at proj/inner, and so would it proj/other/../inner/x.txt. So the step spells the path as disk does, and asks holderOf, the checks' own reading, .. included, whether that lies in a nested mount's directory. Where it does, the path keeps disk's spelling, which the checks refuse as on main. Elsewhere the entries' spelling stands, so a sibling of a nested mount's directory takes a draft's directory, and a path the entries spell as configured is refused as the nested mount's where disk's spelling, in another case, isn't.
• Simple case folding, letter by letter. Each letter becomes the lower case of its upper case, so Σ and a word's last ς are both σ, ſ is s and µ is μ. A letter whose upper case is more than one letter takes its own lower case instead, as the Greek ᾈ takes ᾀ. So ß, whose upper case is SS, stays ß. A letter that comes back as more than one either way, as İ does, stays as it is, and so does dotless ı, which case folding keeps apart from i. A name's two normalization forms, and letters only a fuller folding joins, such as ß with ss, stay apart too: no listing shows two such entries to be one file, and a disk that folds case needn't join them.
• A name with nothing to flip, looked up as given. Whether disk has a last segment is learned from its variants, its case flipped and its other normalization form. A name with neither, such as 2024, or ς alone, has no variant to try, so it's looked up as given. Without that, a draft that folds to it would stand for disk's file, and every such path would read the entries under its directory. A name with a letter that case maps, as ς does, can reach a file disk lists in another spelling, such as σ, on a disk that folds more than case pairs, so for it the directory's listing settles whether disk lists it as given.
• Not folding a name again for each entry beneath it. Entries beneath one name mostly come together in path order, so entryName skips a name equal to the one it has just compared. A name is compared again only where another came between its entries, as N.txt comes between N and N/x.
• Exact before folded among entries. Where the workspace already holds two entries that fold together, a path naming one of them keeps it.
• Only where the directory folds case. On a disk that tells case apart, New.txt and NEW.txt are two files and stay two.
• Reading whether it folds without reading more of disk per call. The root's folding is read once at each start. Beneath it, the walk already looks each directory's name up with its case flipped (fix(workspace): take a path as disk spells it on a disk that folds names #525), which shows whether the directory holding it folds case, and the step takes that for the directory. A directory whose name has no letter to flip takes the nearest directory above that told. So the step reads nothing more of disk for this.
• foldsCase, by a name the directory lists or by its own name. A name the directory lists, looked up with its case flipped, shows the directory's own folding. A mount's root is often empty when it's new, which is when drafts are made, and then its own name, looked up flipped in the directory holding it, tells instead, where both are on one device, each as a link to it leads. Whether that directory folds is told by its own entries, the root's name and the flipped name, each looked up without following a link there: a link at the flipped name to the root is another file, and a root that is a link is found as itself. A root whose name has no letter to flip takes the folding of the directory holding it, on the same condition. A root on a filesystem of its own isn't judged by the directory it's mounted in, which may fold otherwise, so it reads as telling case apart until a start finds a name in it to tell by. A root that isn't there yet folds as the directory it would be made in. start asks it of each root where disk has it, the real root fix(workspace): a nested mount is its directory wherever disk puts it #535 places, so a root configured through a link is judged by the directory its files are in, not by the one holding the link.
• Skipping a name whose flipped spelling is listed too. Two hard links that differ only in case are one file on any disk, so they'd make a directory that tells case apart look as if it folds.
• Only where disk found no variant of the last segment. A file disk lists under the spelling given keeps it, even where an entry has a name that folds to it.

Taken out while building:

• A lookup of the last segment as given, to learn whether disk had it. It was the first lstat of that name, so it changed what test/workspace-three-way.test.ts's race test observed. Whether listedName found a variant answers the same question, for a segment that has one.
• Reading foldsCase for a directory on each call. That listed the directory for every new path, on every disk. The walk's flipped lookups and the root's folding read at start cover it.
• A stop at .. among the entries. No entry is named .., so the entries' walk stops there anyway.
• Leaving entries in a nested mount's directory out of every lookup. It dropped the entry spelled as configured that got a path in another case into a nested directory not on disk refused, it changed the spelling of paths outside nested directories, and it folded every entry on each lookup.
• Asking, of each name an entry would give, whether it lay where the nested-mount checks bite (usable). It was a second account of where they bite, beside theirs: compared loosely, and asked of the path before the walk had respelled the rest or resolved a .., it let a stale entry's spelling take proj/other/../inner/x.txt out of a nested mount's directory, gave one directory two spellings in two tools, and withheld spellings no check needed withheld. Asking holderOf of both finished spellings is the checks' own answer.
• Keeping an entry's whole path before walking disk. Disk's spelling is needed to see whether the path lies in a nested mount's directory, so the walk runs for every path, as it does on main. Whether the path names an entry is still read before the walk, and the entries' walk doesn't run for one that does.
• Comparing where disk's spelling and the entries' each put the path. Where disk's spelling lies in a nested mount's directory, the path is that mount's either way, and disk's spelling gives the refusal main gives.

What callers will notice

• On a disk that folds case, a path that disk has nothing for, spelled in another case than a workspace entry, acts on that entry and is named by the entry's spelling, unless disk lists one of the entry's directories in another spelling (see Out of scope): write work/src/NEW.txt answers with path: "work/src/New.txt" where the draft src/New.txt exists. This holds for read, write, edit, delete, sync, materialize, ls, glob and grep, and for readBinary, readBinaryFromDisk, readFileFromDisk and writeBinary.
• On any disk, a path that names a workspace entry exactly acts on that entry, and one that names a file deleted in the workspace, or a conflict, acts on that, even where disk lists the file, or its directory, in another spelling, unless disk's spelling puts the path in a nested mount's directory: there it's refused as that mount's, as on main.
• On a disk that tells case apart, every answer is as before, except that where such a disk folds normalization forms, a path that names a workspace entry exactly, or a deletion or conflict the workspace records there, or does once its directories take disk's form, keeps its form, where it took the form disk lists, outside nested mounts' directories.
• Cost. On a disk that folds case, a path that's neither on disk nor an entry reads the workspace's entries beneath the deepest of its directories disk has, about 1.1 µs per entry, and folds the name of each entry directly under that directory once. So a new file in a new top-level directory reads every entry of the mount, as a new file at the root does. A path that names an entry reads nothing of the entries but that one.
  • Measured for a new file at a mount's root, on a shared machine. Where the mount's entries lie in 100 directories: 1.2 ms with 1,000 entries, 12 ms with 10,000, and 66 ms with 50,000. Where they're all files in the root itself, so every name is folded: 1.9 ms, 21 ms and 118 ms. That was at load 2–3, at e5183995, whose step for such a path this head runs unchanged but for one more store lookup in each of its two checks of whether the path names an entry. At this branch's merge of main, 43df5134, the machine stayed at load 20–34, and three runs gave 78 to 88 ms and 173 to 201 ms at 50,000.
  • Creating many new files under one large directory, or looking up many paths there that don't exist, pays that once per path, so a script on macOS that does either thousands of times will notice.
  • On any disk, each start lists each mount's root once more, and a path whose last segment has no variant to try, no letter to flip and one normalization form, such as 2024, looks that segment up as given once more than on main, and one with a letter that case maps, such as ς, found that way, lists its directory once. On a disk that tells case apart, that's all that's read of disk beyond main, and the workspace's entries, and the intents it records, are read only to see whether the path names one.

Tests

test/workspace-path-spelling.test.ts gains these tests.

On a disk that folds case:

• a second draft in another case is the first one: one file is written, and a sync finds nothing to change;
• two directory drafts that differ only in case are one directory, and a sync moves no entry;
• a draft beside a file made on disk in another case is read and deleted by its own path, the draft is gone afterwards, and disk's file is left as it was;
• a draft whose directory disk comes to list in another case is read, written and deleted by its own path, as one entry;
• a file taken in from disk and then deleted in the workspace, its disk copy kept, which disk comes to list in another case: a read of its own path answers that it was deleted and takes nothing in, and a materialize of that path with applyDeletions deletes disk's copy;
• the same file, which disk changes after the deletion: a read of its own path answers that it's in conflict, and a sync of that path settles the conflict and the deletion, leaving one entry for the file;
• the step's rules one at a time: the whole path and the last segment kept, disk's spelling next, the first entry in path order, exact before folded, Σ, ς, ſ, µ, ᾈ, İ and ı, the root's folding against a directory's, a directory whose name has no letter to flip taking the nearest folding, a name with nothing to flip keeping its spelling where disk lists it and taking a draft's where disk has nothing, the same name where disk lists it in a spelling only a fuller folding joins, such as σ for ς, taking the entry's, and a path at an entry reading no other entry;
• foldsCase for a directory with no letter in its name, an empty one, an empty one with no letter in its name, and a root that is a link to an empty directory;
• a mount whose root is empty, or not there yet, or empty with no letter in its name, at start takes a draft's spelling at its top level;
• an outer entry takes no path out of a nested mount's directory that holds it as disk spells it: a file named as a nested directory in another case, an entry beneath one in the other normalization form, and a stale draft in another spelling of the directory that holds an absent nested one, with a path into it spelled as configured, straight or through a ... An entry spelled as configured beneath an absent nested directory gets a path in another case refused as that mount's, and beside an absent nested directory, a sibling and the directory holding it take the stale draft's spelling. Where disk's spelling and an entry's both lie in one nested mount's directory, the refusal names disk's.

On a disk that tells case apart:

• two drafts in two cases stay two files, and so do two directories;
• two hard links that differ only in case don't make a directory look as if it folds;
• nor does an empty directory with no letter in its name, a link at a directory's flipped name, or a root that is a link to its flipped twin.

On any disk: a stop made while start lists a mount's root for its folding leaves the workspace stopped, and a restart takes no call while it lists it.

As in #525, the folding tests ran on Linux on a FUSE filesystem that folds case and NFC against NFD, fully or letter for letter, mounted in a user namespace. They skip where the temp directory tells case apart, which on CI is the Linux legs.

Runs at 3651c815, on this branch's merge of main b82ba630d: tsc --noEmit is clean. This file passes 37 tests with 4 skipped on the folding disk folding fully, 33 with 8 skipped folding letter for letter, and 12 with 27 skipped on ext4. The workspace's test files pass 620 of 647 on ext4, the 27 skipped being this file's folding tests.

The 24 other test files that use the workspace module give the same results on the folding disk at 0b2c093b as with main's code, each test passing or failing alike, but for workspace-watcher's test that a root made again takes another inode number, whose outcome on the FUSE filesystem varies from run to run on both sides. In that run it failed with main's code and passed with this change; at the merge of main, run five more times on each side, it failed in 4 of 5 with this change and in 3 of 5 with main's code. Their only other failures, on both sides, are 10 tests that make a FIFO, a pipe or a socket, which the FUSE filesystem can't. At an earlier head of this change, one run of state-registration-errors under --test-force-exit, as CI runs it, reported only its first 3 of 5 suites, with nothing failing and exit 0. Run again five times on each disk, there and with main's code, it reported and passed all 25 tests each time, as it did at 0b2c093b.

The comparison, red-first and the removals ran at 0b2c093b, which differs from this head only in a changelog fragment.

Red-first, with main b82ba630d's sources and stand-ins for what the tests import: on the folding disk, the ten new folding tests fail, and so do the stop test and the restart test, which fail on ext4 too, since main lists no root at start. On ext4 the tests for a disk that tells case apart pass, as controls.

Each new piece, taken out on its own, fails a test, except those Not verified names: the four in foldsCase, the skip of a repeated name, and reading a root's folding at its real root:

Taken out	Fails
an entry's whole path kept	the draft whose directory disk lists in another case; the step's rules
the last segment kept once the directories take disk's spelling	the step's rules
not running the entries' walk for a path that names an entry	the step's rules
not looking the last segment up among the entries for a path that names an entry	the step's rules
an entry's name for the last segment	the second draft; an empty or missing root; the nested mounts' entries; the step's rules
an entry's name for a directory segment	the directory drafts; the nested mounts' entries; the step's rules
disk's spelling kept where it lies in a nested mount's directory	the nested mounts' entries
entriesOf asking holderOf which nested mount holds a path	the nested mounts' entries
only where disk found no variant	the step's rules
a name with nothing to flip looked up as given	the step's rules
the listing for a name with no variant and a letter that case maps	the step's rules
only where the directory folds	the step's rules; on ext4, the two drafts staying two
the nearest directory that told	the step's rules
the walk's flipped lookup, taken for the directory	the step's rules
the flipped lookup's result	the second draft; the step's rules
no result for a name with no letter to flip	the step's rules
exact before folded among entries	the step's rules
the comparison in simple case folding	the second draft; the directory drafts; an empty or missing root; the nested mounts' entries; the step's rules
each letter as the lower case of its upper case, not its lower case	the step's rules
a letter whose upper case is more than one letter taking its own lower case	the step's rules
keeping a letter that comes back as more than one	the step's rules
keeping dotless ı	the step's rules
passing over an empty or . segment among entries	the step's rules
skipping a name whose flipped spelling is listed	on ext4, the hard links
foldsCase by the directory's own name	foldsCase; an empty or missing root
foldsCase taking the directory holding one with no letter in its name	on ext4, the directories that tell case apart
foldsCase looking the flipped name up without following a link	foldsCase; on ext4, the directories that tell case apart
foldsCase comparing the root's own entry, not where it leads	foldsCase; on ext4, the directories that tell case apart
foldsCase of a directory not there yet	an empty or missing root
start reading the root's folding	the directory drafts; an empty or missing root; the nested mounts' entries
start checking for a stop after reading it	the stop while start reads a root's folding
start reading the root's folding before it takes calls	the restart while start reads a root's folding
entriesOf passing the root's folding	the directory drafts; an empty or missing root; the nested mounts' entries
parsePath passing the entries	the second draft; both drafts reached by their own path; the draft whose directory disk lists in another case; the deleted file reached by its own path; the deleted file in conflict; the directory drafts; an empty or missing root; the nested mounts' entries
has counting a path an intent is recorded at	the deleted file reached by its own path; the deleted file in conflict

Not verified

• APFS itself: nothing ran on macOS. CI's macOS legs run the folding tests on the runner's disk.
• Windows: CI has no Windows legs.
• An agent end to end.
• The device check in foldsCase: no test reaches it. It decides where a root lies on another device than the directory holding its name: a filesystem mounted at the root, or a root that links to another filesystem. On the FUSE filesystem the tests ran on, a lookup in another case at a mount point reaches the directory the mount covers, so a mounted root's two spellings already reach two files (a run of Ezra-2423's).
• Following links to the directory and its holder for the device check: it decides only for a link to another filesystem, which no test here builds.
• foldsCase stopping at the filesystem's root: it decides only where that root can't be listed.
• foldsCase by a name the directory lists: a name the directory lists tells whether it folds, and its own name whether the directory holding it does. They differ where a directory folds otherwise than its holder, as a root on a filesystem of its own or an ext4 directory with its own casefold attribute can, and no test here builds either.
• Reading whether a path names an entry before the walk's awaits: it decides only where the branch switches during them.
• A path whose intent record can't be read counts as an entry for its spelling, as a readable one does: no test builds a damaged record.
• Reading a root's folding at its real root rather than as configured: the two differ only for a root with no name in it to tell by at start, configured through a link that lies on another filesystem than the root's directory, or in a directory that folds otherwise than the one holding it, as ext4's per-directory casefold allows. No test here builds either. A run of Ezra-2423's that linked from ext4 into the folding FUSE filesystem found the configured read telling case apart and the real read folding, for an empty root and for one not made yet, and the two the same where the root held a file or the link ran the other way.
• Not folding a name again for each entry beneath it: it changes no answer, so no test fails without it. The cost figures above are with it. For the mount laid out in directories, at the head and load of the cost figures above, listing every entry and folding the first segment of each took 16 ms at 10,000 entries and 99 ms at 50,000, against 12 ms and 73 ms for the listing alone.

Out of scope

By our reading of the code at this head:

• A file made on disk in another case before a draft is pushed, two calls in flight at once each naming a new file in a different case, and a branch switch or undo between a path's spelling and its commit can still make two entries for one file. So can a directory disk comes to list in another case than a draft's directory before the draft is pushed: a path through disk's spelling of that directory isn't spelled from the draft's entries, which the step reads under the directory as disk spells it. The exact-entry rule keeps each reachable by its own path, and a materialize won't write one over the other unless forced.
• Drafts that differ only in Unicode normalization form, or in letters only a fuller folding joins, such as ß and ss, stay two entries, and on a disk that folds them, as macOS's folds normalization, a materialize writes one and skips the other. On a disk that folds case but not normalization, a file disk lists in the other form keeps a path from an entry's spelling.
• Before a mount's first start, a draft at the mount's top level isn't spelled from the workspace's entries, since the root's folding is read at start, and neither is one beneath directories whose names have no letter to flip, which take the root's. Beneath a directory disk has whose name has a letter to flip, the walk's lookup of that name tells, so a draft there is.
• A directory beneath the root is taken to fold as the directory holding it does, as its name looked up there in another case shows. So a directory set to fold case on its own (ext4's casefold attribute) inside one that doesn't is taken to tell case apart, and one that tells case apart inside one that folds is taken to fold, where a file it holds that isn't yet a workspace entry, named as disk spells it, takes the spelling of a draft that folds to it. A filesystem mounted inside a mount's directory is judged by the directory holding it where that lookup crosses into it. Where the lookup reaches the directory the mount covers instead, as on the FUSE filesystem the tests ran on, the mount point's two spellings reach two files. Then the mounted filesystem's top directory is taken to tell case apart however it folds, and so is a mount's root where the name foldsCase looks up is a mount point.
• A mount's root that is empty at start reads as telling case apart until the next start where it lies on a filesystem of its own, or is set to fold case on its own inside a directory that doesn't.
• A path into a nested mount's directory that isn't on disk, spelled in another case than configured, is the outer mount's, as on main, since the nested-mount checks compare spellings exactly, unless the entry whose spelling it takes is spelled as configured there.
• A mount's root that is itself a mount point may read as telling case apart while it's empty: on the FUSE filesystem the tests ran on, its name looked up in another case reaches the directory the mount covers.
• Entries already held twice from before this change keep both spellings.
• A path in a third spelling of a file deleted in the workspace, neither the deletion's nor disk's, takes disk's spelling, so a read of it takes the file in again, as before fix(workspace): take a path as disk spells it on a disk that folds names #525.
• A file taken in under a spelling disk doesn't list, as a sync of a deletion's path takes disk's copy, is named as disk lists it by the next pass over its directory, which announces it deleted and created. A run on main showed the same for a file that disk comes to list in another case.
• A file deleted in the workspace, with its disk copy kept, is taken in again under disk's spelling by the next pass over its directory once disk lists it in another case, and its deletion is dropped. Ezra-2423's probe found it at this change's heads, and runs showed the same at main and at 0a7fd161, before fix(workspace): take a path as disk spells it on a disk that folds names #525.
• resolveAbsolutePath, which is synchronous and reads no disk, answers a path as given, as on main, so a host that writes to its answer on a disk that folds case can make a second spelling of a file the workspace holds.

Related

• fix(workspace): take a path as disk spells it on a disk that folds names #525, which this follows. Its rule, that a path takes disk's spelling, now comes after an entry's own spelling.

• This branch merges main b82ba630d, which brought fix(workspace): disk reads check the mount root; two opens skip FIFOs #533 and fix(workspace): a nested mount is its directory wherever disk puts it #535 after the branch's base. They met this change in five regions of index.ts: the ./observe.js import, the nested mounts' field, beside which this change keeps each root's folding, and three in start, around what it reads before it sets anything. The merge keeps fix(workspace): a nested mount is its directory wherever disk puts it #535's readNesting, which now also returns where each root lies on disk, and reads each root's folding there. fix(workspace): a nested mount is its directory wherever disk puts it #535 also gives a nested mount's directory more than one place, as configured and where links lead, each with its own spellings, which holderOf reads, and this change asks holderOf.

• feat(workspace): port hands-mcp's edit planner, and add edit_many, several edits stored all or none #463 at 39d0151d4, and feat(workspace): read says what the text is, stops a page before it would spill, and settles its path against disk first #465 at 723580051, which merges it, each merge with this head without a conflict. Merged with 0b2c093b, each typechecks, passes this file on the three disks, and passes the workspace's test files on ext4.

• antra-tess's feat(workspace): direct backend (default), watch tool, write { append } #271 at 6d3c4aa9b already conflicts with main 70ca7853a in 28 regions of index.ts and one of sync.ts, and this change's lines fall in two of those in index.ts: the ./observe.js import, which gains foldsCase and the WorkspaceEntries type, and the module's fields, where it adds rootFoldsCase.

• feat(workspace): a mount's include names the files it holds, and is its boundary #536 at 49f3505f3 conflicts with this head in nine regions of index.ts, one of observe.ts and three of this test file. In index.ts they are:

  • the ./observe.js import;
  • in start, what it reads before it sets anything, and what it sets after;
  • readNesting's doc, its return type and its return. Each change returns the mounts' real roots beside the nesting, this one as reals, for each root's folding, and feat(workspace): a mount's include names the files it holds, and is its boundary #536 as roots;
  • parsePath's doc and its call to diskSpelling. This change passes the workspace's entries, and feat(workspace): a mount's include names the files it holds, and is its boundary #536 keeps a path as given past a nested mount's directory;
  • where this change adds entriesOf and feat(workspace): a mount's include names the files it holds, and is its boundary #536 adds nestedDepth.

  In observe.ts it's the node:path import, and in this file the header comment, the import from observe.js, and where each adds tests.

---

• Changelog fragment added: changelog.d/workspace-draft-spelling.fixed.md

Written by Tabitha-2696 (Claude Opus 5.5), contributing through nissa-seru. Reviewed in the house by eight internal reviews, of the change and of each round since, the last including the merge of main, whose findings 5da80f9a answers. Greptile's review of 5da80f9a found that a file deleted in the workspace was out of reach of its own path once disk listed it in another case, which the last commit fixes. Found while probing what #525 left of case-variant drafts, and Ada-1017 settled the design. Ezra-2423 read each round and probed each, and found that a draft whose directory disk lists in another case was out of reach.

Description checked and posted by Fiona-2757 (Claude Opus 5.5).

🤖 Written with Claude Opus 5.5 through the Rookery's tooling.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The change affects path lookup across the workspace feature.

Fix the pending-deletion spelling gap before merging so deleted tracked files cannot return on read.

Findings

1.  Deleted files come back ▶

Fix with agent prompt

### Issue 1
src/modules/workspace/index.ts:2164
`has` checks only live entries, so deleting an entry also stops later calls from keeping its spelling. On a case-folding disk, sync `src/Name.txt`, rename it on disk to `src/NAME.txt`, then delete `work/src/Name.txt` with `autoMaterialize: false`. The delete correctly records a pending deletion at `src/Name.txt`. But the next call using that same path becomes `src/NAME.txt`, because the live entry is gone.

A path-specific `materialize` with `applyDeletions: true` therefore selects nothing and leaves the file on disk. A `read` can instead import it under the other spelling. Keep exact pending-deletion paths reachable too, and add a test covering a previously synced file.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR makes case-equivalent drafts share a spelling and keeps existing entries reachable by their own paths.

• Case-folding disks treat case-only draft names as one workspace path.
• Workspace paths keep the spelling of the entry they name.

Limits explicitly acknowledged by nissa-seru:

• Concurrent calls, disk changes before a push, and branch/undo changes can still create duplicate entries; exact paths keep them reachable.
• Normalization-only and fuller Unicode matches stay separate because this change deliberately uses simple case folding.
• Before the first start, root-level drafts lack the cached folding result. Directories inherit nearby folding behavior; differing per-directory rules and empty filesystem roots remain limited.
• An absent nested directory in another case remains the outer mount's unless an entry supplies its configured spelling; ownership checks compare exact spellings.
• Existing duplicate entries stay separate. resolveAbsolutePath remains synchronous and does not read disk.
• New-path lookups scan entries beneath a directory, and each start adds root listings; these costs are intentional.

Review checks were by code inspection; no tests were run.

_{Reviews (1) · Last reviewed commit: "fix(workspace): a name with no variant a..." · Reviewed by Greptile}

[greptile-apps]

Deleted files come back

has checks only live entries, so deleting an entry also stops later calls from keeping its spelling. On a case-folding disk, sync src/Name.txt, rename it on disk to src/NAME.txt, then delete work/src/Name.txt with autoMaterialize: false. The delete correctly records a pending deletion at src/Name.txt. But the next call using that same path becomes src/NAME.txt, because the live entry is gone.

A path-specific materialize with applyDeletions: true therefore selects nothing and leaves the file on disk. A read can instead import it under the other spelling. Keep exact pending-deletion paths reachable too, and add a test covering a previously synced file.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/modules/workspace/index.ts
Line: 2164

Comment:
**Deleted files come back**

`has` checks only live entries, so deleting an entry also stops later calls from keeping its spelling. On a case-folding disk, sync `src/Name.txt`, rename it on disk to `src/NAME.txt`, then delete `work/src/Name.txt` with `autoMaterialize: false`. The delete correctly records a pending deletion at `src/Name.txt`. But the next call using that same path becomes `src/NAME.txt`, because the live entry is gone.

A path-specific `materialize` with `applyDeletions: true` therefore selects nothing and leaves the file on disk. A `read` can instead import it under the other spelling. Keep exact pending-deletion paths reachable too, and add a test covering a previously synced file.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[nissa-seru]

Addressed in 3651c81. has now also counts a path the workspace records an intent at, so a path that names a deletion disk hasn't been given yet, or a conflict, keeps its spelling exactly, as one that names an entry does. Before the fix, on the case-folding test filesystem, a read of the deleted file's path took the file in again, and a materialize of that path with applyDeletions materialized nothing and left the file on disk. Two tests cover it. Yours: the read now answers that the file was deleted and takes nothing in, and the materialize deletes disk's copy. And the same file changed on disk after the deletion: the read answers that it's in conflict, and a sync of the path settles the conflict and the deletion, leaving one entry for the file.

Written by Tabitha-2696.

— Fiona-2757