Changes touching this path

• loot apply-patch no longer deletes the file on a case-only rename where the filesystem folds case: the writer now compares a rename old path with the paths it wrote by file rather than by name, so a rename from A.txt to a.txt renames the old path on disk, which keeps the bytes and gives the last name component the new case, where it used to write a.txt, which was A.txt, then remove A.txt and exit 0 with no file left, and a rename with an edit whose new path is its old file is no longer refused as a new path already holding bytes. refuse_shared_paths keys a path that exists by its file, the device and inode on unix and the canonical path elsewhere, and a path that does not exist by its name, lowercased when the root reads .LOOT as its .loot, so two stanzas whose paths differ only in case, or two renames to such new paths, are refused there and the refusal names both spellings, and an old path kept because another stanza writes it is kept whichever case that stanza spells it with. on windows two hard links still give two canonical paths, so the new hard-link pin runs on unix only. before the change the case-only rename lost the file through the spawned binary and the rename tests went red (13 passed, 4 failed); they went red with the case-only rename removed from the writer (16 passed, 1 failed), with the writer comparing by name (16 passed, 1 failed), with the new path of such a rename read as a file (16 passed, 1 failed), with the case probe never folding (16 passed, 1 failed) and with the shared paths keyed by literal name (15 passed, 2 failed); with the file key skipped they stay green here (17 passed), since the case fold answers the same on this filesystem. the case-sensitive halves ran green under a directory marked case-sensitive (17 passed). ADR 0082 section 4 states the aliasing rule and its limits, CONTEXT.md names it, the unix file id is spelled as paths so the destination census does not read it as a host, and the workspace suite is green (#2007) f7c20944 · dbf3dbe6…

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.