fix(fuse): a file renamed while its upload is read back keeps its new name (B172)

docs/BUGS.md

@@ -12,6 +12,31 @@ Conventions:
 
 ---
 
+## B172 — A file renamed while its upload is read back shows its old name
+
+**Status:** Fixed (unverified).
+**Found:** 2026-10-04, by `one_client_on_a_good_link` (seed 8) on 2502af6, run three at a time
+in a loop: two of nine runs failed. In one, a write to `f.txt` answered `ENOENT`; in the other,
+a rename of `f.txt`. The mount showed the file as `a.txt` again.
+
+**Where:** `refresh_after_upload` and `place_landed` in `crates/pdfs-fuse/src/drain.rs`.
+
+**Cause.** `a.txt` was renamed to `f.txt` while its create was on the wire, with a write behind
+it. The create landed, and its op became a revision with a rename queued after it. The upload
+retires its op before it reads the node back, so the rename went out while Drive answered the
+read-back, and that answer still had the old name. The drain asked whether a rename was queued
+only after the answer came, found none, and put `a.txt` back into the tree. The create's
+read-back already asks first (B161); the upload's did not.
+
+**Fix.** The upload's read-back notes whether a rename is queued, and where the tree has the
+file, before it asks Drive. The tree keeps the name and folder the user gave the file if a
+rename was queued then or is now, or if the file moved meanwhile.
+
+**Test:** `a_file_renamed_while_its_upload_is_read_back_keeps_its_new_name` in
+`crates/pdfs-fuse/src/sim/daemon.rs`.
+
+---
+
 ## B171 — A file deleted while its upload fails stays on Drive for the upload's backoff
 
 **Status:** Fixed (unverified).

docs/CHANGELOG.md

@@ -73,7 +73,8 @@ by its local id, in the queue, the stored tree and pins alike.
 - **A file deleted while its upload was retrying is removed from Drive right away.** It no
   longer waits for the upload's next retry (B171).
 - **A file renamed just as its upload finished keeps its new name.** The mount no longer showed
-  the old name, and a second rename no longer failed with "No such file or directory" (B152).
+  the old name, and a second rename no longer failed with "No such file or directory" (B152,
+  B172).
 - **A change that waits for a name to be freed no longer waits seconds after it is.** A rename or
   upload over a file being deleted goes out as soon as the delete lands (B153).
 - **A file deleted right after it was made no longer stays on Drive when the link lost Drive's

docs/MILESTONE-3.0.0-STATUS.md

@@ -9,7 +9,7 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
 - **Phase 2**: local ids, inode = local id, one tree for every mount (2.10.0).
 - **Phase 3, first part**: mkdir, create, rename, unlink and rmdir on the mount are recorded
   locally and sent from the queue; `"local_first": false` brings back the old path (5e0f30c).
-- Fixes from the simulation and account runs since then: B127 and B141 to B171.
+- Fixes from the simulation and account runs since then: B127 and B141 to B172.
 - **Sync issues, first cut** (§6.2): refusals sorted into issues, shown at once in the app,
   tray and CLI; Export button and `pdfs sync export`; `pdfs sync issues`.
 
@@ -114,7 +114,8 @@ Tracks `docs/MILESTONE-3.0.0.md`. Update it with every commit that moves a phase
          `one_client_on_a_good_link`: a write opened as an upload landed took the revision
          it replaced as its base, and the next write failed with `EIO` (B170, fixed). The
          suite's seed 9 found a deleted file's trash waiting out its create's backoff (B171,
-         fixed).
+         fixed). Run three at a time on 2502af6, seed 8 failed two of nine runs: a file renamed
+         while its upload was read back showed its old name again (B172, fixed).
 5. **Release**: 2.10.0 is tagged; the 2.9.0 tag still waits for the user's go-ahead.
 
 ## After 3.0.0