Add Phase 10 File Organizer - #82
Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f0d840fd34
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 076ed6f250
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3fcb7688d0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review Full review of the entire PR, not only the latest diff. Please review the full 22-file PR on current HEAD Please inspect the entire PR for any remaining correctness, safety, resource-lifetime, portability, test, documentation, or scope issue. If there are no suggestions, please leave the clean-review 👍 reaction as usual. Do not merge. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a3c7c07af0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex address the two unresolved Review 15 P2 findings on the current HEAD. Please keep the change tightly scoped to recovery correctness: (1) eliminate the post-verification/pre-close recovery-path race without claiming stronger protection against later external namespace changes than can actually be guaranteed, and (2) fsync the anchored root directory so the newly created recovery directory entry is crash-durable before reporting recovery. Add focused regressions for both findings, keep EN/PT-BR/ES documentation consistent if the recovery contract wording changes, run the focused File Organizer tests, and do not merge or delete the branch. |
Summary
Testing
|
|
@codex please provide the exact unified diff for your completed local commit |
|
I can’t provide the requested exact patch because commit Checks
Once git diff --no-ext-diff --no-color --full-index --binary \
a3c7c07af0fe0bafe6595f9efb38f6d5a170b6c0 \
c497a74 |
|
@codex re-apply the Review 15 recovery fix from scratch on a fresh workspace based on current PR HEAD |
Summary
Testing
Complete unified diffdiff --git a/practical-projects/06-file-organizer/README.es.md b/practical-projects/06-file-organizer/README.es.md
index 9085474..5a7fb4a 100644
--- a/practical-projects/06-file-organizer/README.es.md
+++ b/practical-projects/06-file-organizer/README.es.md
@@ -273,7 +273,7 @@ Los errores concurrentes pueden dejar estado incierto. La recuperación prioriza
Si la ejecución ya movió el origen al staging y después detecta una condición insegura, puede crear un hard link no-replace de vuelta al nombre de origen cuando sea posible. No elimina a ciegas el staging.
-Un pathname de staging no funciona como lock de inode. Después de reclamar el origen, cada ruta de fallo vuelve a comprobar si la entrada de staging todavía coincide con la identidad fijada del origen. Si coincide, la ejecución puede intentar recrear el nombre original mediante un hard link no-replace desde ese staging comprobado, pero la restauración solo se acepta después de volver a leer el propio pathname recreado del origen y verificar que conserva la identidad fijada. Si el link falla, sufre una carrera hacia otro objeto, deja ausente el nombre de origen o la identidad posterior al link no coincide, la ejecución deja intactas las entradas inciertas y, antes de cerrar el descriptor todavía fijado del origen, copia los bytes planificados a un archivo regular exclusivo `.fo-recovery-*`. Ese recovery no se informa como conservado solo porque su descriptor se haya escrito y `fsync()` haya terminado: mientras el descriptor de recovery sigue abierto, la ejecución vuelve a leer el pathname de recuperación a través de la raíz anclada y exige que nombre el mismo archivo regular `(st_dev, st_ino)`. Si el pathname desaparece, se renombra o se reemplaza, la ejecución falla en lugar de afirmar falsamente que los datos quedaron retenidos, sin borrar ni sobrescribir entradas inciertas de terceros. Esto también cubre un fallo final de `RENAME_NOREPLACE` causado por un destino que aparece después de una carrera sobre el staging. Si un staging de reemplazo se renombra con éxito y la verificación de identidad del destino detecta la divergencia, el destino ajeno también queda intacto mientras se recuperan los bytes fijados. La recuperación solo afirma conservación cuando el propio pathname usado para informarla queda demostrado.
+Un pathname de staging no funciona como lock de inode. Después de reclamar el origen, cada ruta de fallo vuelve a comprobar si la entrada de staging todavía coincide con la identidad fijada del origen. Si coincide, la ejecución puede intentar recrear el nombre original mediante un hard link no-replace desde ese staging comprobado, pero la restauración solo se acepta después de volver a leer el propio pathname recreado del origen y verificar que conserva la identidad fijada. Si el link falla, sufre una carrera hacia otro objeto, deja ausente el nombre de origen o la identidad posterior al link no coincide, la ejecución deja intactas las entradas inciertas y, antes de cerrar el descriptor todavía fijado del origen, copia los bytes planificados a un archivo regular exclusivo `.fo-recovery-*`. Ese recovery no se informa como conservado solo porque su descriptor se haya escrito y sincronizado. La ejecución primero llama a `fsync()` sobre el archivo de recuperación y luego sobre el directorio raíz anclado, haciendo duraderos frente a fallos tanto el contenido como la nueva entrada de directorio. Cierra el descriptor de recovery antes de la comprobación final en un punto temporal, vuelve a leer entonces el pathname de recuperación a través de la raíz anclada y exige que nombre el mismo archivo regular `(st_dev, st_ino)`. Si el pathname desaparece, se renombra o se reemplaza en esa comprobación final, la ejecución falla en lugar de afirmar falsamente que los datos quedaron retenidos, sin borrar ni sobrescribir entradas inciertas de terceros. Esta prueba no puede impedir que un agente externo cambie el namespace después de la comprobación. Esto también cubre un fallo final de `RENAME_NOREPLACE` causado por un destino que aparece después de una carrera sobre el staging. Si un staging de reemplazo se renombra con éxito y la verificación de identidad del destino detecta la divergencia, el destino ajeno también queda intacto mientras se recuperan los bytes fijados. La recuperación solo afirma conservación cuando el propio pathname usado para informarla queda demostrado.
Por ello, la ejecución segura en Linux exige deliberadamente permiso de lectura para cada archivo regular planificado. La legibilidad se valida antes de crear los directorios de categoría y de nuevo al fijar el inode del origen para la mutación; los fallos de permisos se informan como `PermissionError`, no como un falso cambio de identidad del origen.
diff --git a/practical-projects/06-file-organizer/README.md b/practical-projects/06-file-organizer/README.md
index 8eb1fd5..eaabaab 100644
--- a/practical-projects/06-file-organizer/README.md
+++ b/practical-projects/06-file-organizer/README.md
@@ -273,7 +273,7 @@ Concurrency errors can leave uncertain state. Recovery therefore favors preserva
If execution has already claimed the source into a staging entry and later detects an unsafe condition, it may create a no-replace hard link back to the original source name when possible. It does not blindly delete the staging entry.
-A staging pathname is not an inode lock. After the source has been claimed, every failure path rechecks whether the staging entry still matches the pinned source identity. If it does, execution may attempt a no-replace hard link from that proven stage back to the original source name, but restoration is accepted only after the recreated source pathname itself is re-read and verified to have the pinned identity. If the link fails, races to a different object, leaves the source name missing, or the post-link source identity does not match, execution leaves uncertain entries untouched and, before closing the still-pinned source file descriptor, copies the planned source bytes into an exclusive `.fo-recovery-*` regular file. That recovery file is not reported as retained merely because its descriptor was written and `fsync()` completed: while the recovery descriptor is still open, execution re-reads the recovery pathname through the anchored root and requires it to name the same regular-file `(st_dev, st_ino)`. A missing, renamed, or replaced recovery pathname raises instead of falsely claiming durable retention, and uncertain third-party entries are not deleted or overwritten. This also covers a final `RENAME_NOREPLACE` failure caused by a destination that appears after the stage was raced. If a replacement stage is successfully renamed and destination identity verification detects the mismatch, the unrelated destination is likewise left intact while the pinned bytes are recovered. Recovery preserves data only when the pathname used to report that preservation is itself proven.
+A staging pathname is not an inode lock. After the source has been claimed, every failure path rechecks whether the staging entry still matches the pinned source identity. If it does, execution may attempt a no-replace hard link from that proven stage back to the original source name, but restoration is accepted only after the recreated source pathname itself is re-read and verified to have the pinned identity. If the link fails, races to a different object, leaves the source name missing, or the post-link source identity does not match, execution leaves uncertain entries untouched and, before closing the still-pinned source file descriptor, copies the planned source bytes into an exclusive `.fo-recovery-*` regular file. That recovery file is not reported as retained merely because its descriptor was written and synchronized. Execution first calls `fsync()` on the recovery file and then on the anchored root directory so both the contents and new directory entry are crash-durable. It closes the recovery descriptor before the final point-in-time check, then re-reads the recovery pathname through the anchored root and requires it to name the same regular-file `(st_dev, st_ino)`. A missing, renamed, or replaced recovery pathname at that final check raises instead of falsely claiming retention, and uncertain third-party entries are not deleted or overwritten. This proof cannot prevent an external actor from changing the namespace after the check. This also covers a final `RENAME_NOREPLACE` failure caused by a destination that appears after the stage was raced. If a replacement stage is successfully renamed and destination identity verification detects the mismatch, the unrelated destination is likewise left intact while the pinned bytes are recovered. Recovery preserves data only when the pathname used to report that preservation is itself proven.
Safe Linux execution therefore deliberately requires read access to each planned regular file. Readability is validated before category directories are created and again when the source inode is pinned for mutation; permission failures are reported as `PermissionError`, not as a false source-identity change.
diff --git a/practical-projects/06-file-organizer/README.pt-BR.md b/practical-projects/06-file-organizer/README.pt-BR.md
index 4771273..5153b87 100644
--- a/practical-projects/06-file-organizer/README.pt-BR.md
+++ b/practical-projects/06-file-organizer/README.pt-BR.md
@@ -273,7 +273,7 @@ Erros concorrentes podem deixar estado incerto. A recuperação prioriza preserv
Se a execução já moveu a origem para staging e depois detecta condição insegura, ela pode criar um hard link no-replace de volta para o nome de origem quando possível. Ela não apaga cegamente o staging.
-Um pathname de staging não funciona como lock de inode. Depois que a origem foi claimada, todo caminho de falha revalida se a entrada de staging ainda corresponde à identidade pinada da origem. Se corresponder, a execução pode tentar recriar o nome original por hard link no-replace a partir desse staging comprovado, mas a restauração só é aceita depois que o próprio pathname recriado da origem é relido e verificado com a identidade pinada. Se o link falhar, sofrer corrida para outro objeto, deixar o nome de origem ausente ou a identidade pós-link não corresponder, a execução deixa entradas incertas intactas e, antes de fechar o descritor ainda pinado da origem, copia os bytes planejados para um arquivo regular exclusivo `.fo-recovery-*`. Esse recovery não é reportado como preservado apenas porque seu descritor foi gravado e o `fsync()` terminou: enquanto o descritor do recovery ainda está aberto, a execução relê o pathname de recuperação pelo root ancorado e exige que ele aponte para o mesmo arquivo regular `(st_dev, st_ino)`. Se o pathname sumir, for renomeado ou substituído, a execução falha em vez de afirmar falsamente que os dados foram retidos, sem excluir nem sobrescrever entradas incertas de terceiros. Isso também cobre uma falha final de `RENAME_NOREPLACE` causada por um destino que aparece depois de uma corrida sobre o staging. Se um staging substituto for renomeado com sucesso e a verificação de identidade do destino detectar a divergência, o destino alheio também permanece intacto enquanto os bytes pinados são recuperados. A recuperação só afirma preservação quando o próprio pathname usado para reportá-la é comprovado.
+Um pathname de staging não funciona como lock de inode. Depois que a origem foi claimada, todo caminho de falha revalida se a entrada de staging ainda corresponde à identidade pinada da origem. Se corresponder, a execução pode tentar recriar o nome original por hard link no-replace a partir desse staging comprovado, mas a restauração só é aceita depois que o próprio pathname recriado da origem é relido e verificado com a identidade pinada. Se o link falhar, sofrer corrida para outro objeto, deixar o nome de origem ausente ou a identidade pós-link não corresponder, a execução deixa entradas incertas intactas e, antes de fechar o descritor ainda pinado da origem, copia os bytes planejados para um arquivo regular exclusivo `.fo-recovery-*`. Esse recovery não é reportado como preservado apenas porque seu descritor foi gravado e sincronizado. A execução primeiro chama `fsync()` no arquivo de recuperação e depois no diretório root ancorado, tornando duráveis contra falha tanto o conteúdo quanto a nova entrada de diretório. Ela fecha o descritor do recovery antes da verificação final em um ponto no tempo, relê então o pathname de recuperação pelo root ancorado e exige que ele aponte para o mesmo arquivo regular `(st_dev, st_ino)`. Se o pathname sumir, for renomeado ou substituído nessa verificação final, a execução falha em vez de afirmar falsamente que os dados foram retidos, sem excluir nem sobrescrever entradas incertas de terceiros. Essa comprovação não impede que um agente externo altere o namespace depois da verificação. Isso também cobre uma falha final de `RENAME_NOREPLACE` causada por um destino que aparece depois de uma corrida sobre o staging. Se um staging substituto for renomeado com sucesso e a verificação de identidade do destino detectar a divergência, o destino alheio também permanece intacto enquanto os bytes pinados são recuperados. A recuperação só afirma preservação quando o próprio pathname usado para reportá-la é comprovado.
Por isso, a execução segura no Linux exige deliberadamente permissão de leitura para cada arquivo regular planejado. A legibilidade é validada antes da criação das pastas de categoria e novamente ao pinar o inode da origem para a mutação; falhas de permissão são reportadas como `PermissionError`, e não como uma falsa mudança de identidade da origem.
diff --git a/practical-projects/06-file-organizer/file_organizer.py b/practical-projects/06-file-organizer/file_organizer.py
index 7cbce40..0065d8a 100644
--- a/practical-projects/06-file-organizer/file_organizer.py
+++ b/practical-projects/06-file-organizer/file_organizer.py
@@ -732,24 +732,28 @@ def _recover_pinned_source_at(
view = view[written:]
os.fchmod(recovery_fd, mode)
os.fsync(recovery_fd)
-
- try:
- recovery_path_identity = _regular_identity_at(
- recovery_name,
- directory_fd=root_fd,
- )
- except OSError as exc:
- raise RuntimeError(
- f"recovery pathname changed during execution: {recovery_name}"
- ) from exc
- if recovery_path_identity != recovery_identity:
- raise RuntimeError(
- f"recovery pathname changed during execution: {recovery_name}"
- )
+ os.fsync(root_fd)
finally:
os.lseek(source_fd, original_offset, os.SEEK_SET)
os.close(recovery_fd)
+ # Closing the recovery FD before this final proof removes a check-to-close
+ # window. This proves only what the pathname names at this instant; an
+ # external actor can still change the namespace after verification.
+ try:
+ recovery_path_identity = _regular_identity_at(
+ recovery_name,
+ directory_fd=root_fd,
+ )
+ except OSError as exc:
+ raise RuntimeError(
+ f"recovery pathname changed during execution: {recovery_name}"
+ ) from exc
+ if recovery_path_identity != recovery_identity:
+ raise RuntimeError(
+ f"recovery pathname changed during execution: {recovery_name}"
+ )
+
return recovery_name
diff --git a/practical-projects/06-file-organizer/tests/test_atomic_move.py b/practical-projects/06-file-organizer/tests/test_atomic_move.py
index f7e3873..5aa0b4f 100644
--- a/practical-projects/06-file-organizer/tests/test_atomic_move.py
+++ b/practical-projects/06-file-organizer/tests/test_atomic_move.py
@@ -39,7 +39,10 @@ def test_recovery_path_removed_during_fsync_is_not_reported_as_retained(
monkeypatch.setattr(file_organizer.os, "fsync", unlink_recovery_during_fsync)
try:
- with pytest.raises(RuntimeError, match="recovery pathname changed during execution"):
+ with pytest.raises(
+ RuntimeError,
+ match="recovery pathname changed during execution",
+ ):
file_organizer._recover_pinned_source_at(
source_fd,
source.name,
@@ -57,6 +60,91 @@ def test_recovery_path_removed_during_fsync_is_not_reported_as_retained(
os.close(root_fd)
+def test_recovery_path_removed_after_fd_close_is_not_reported_as_retained(
+ monkeypatch: pytest.MonkeyPatch,
+ tmp_path: Path,
+) -> None:
+ if not file_organizer._supports_secure_directory_fds():
+ pytest.skip("secure directory descriptors are unavailable on this platform")
+
+ source = tmp_path / "notes.txt"
+ source.write_text("planned source", encoding="utf-8")
+ root_fd = file_organizer._open_source_directory_fd(tmp_path)
+ source_fd = os.open(source, os.O_RDONLY)
+ original_close = os.close
+ recovery_unlinked = False
+
+ def unlink_recovery_after_close(fd: int) -> None:
+ nonlocal recovery_unlinked
+ original_close(fd)
+ if fd in {source_fd, root_fd} or recovery_unlinked:
+ return
+ recovery_files = list(tmp_path.glob(".fo-recovery-*"))
+ if recovery_files:
+ assert len(recovery_files) == 1
+ recovery_files[0].unlink()
+ recovery_unlinked = True
+
+ monkeypatch.setattr(file_organizer.os, "close", unlink_recovery_after_close)
+
+ try:
+ with pytest.raises(
+ RuntimeError,
+ match="recovery pathname changed during execution",
+ ):
+ file_organizer._recover_pinned_source_at(
+ source_fd,
+ source.name,
+ root_fd=root_fd,
+ )
+
+ assert recovery_unlinked
+ assert not list(tmp_path.glob(".fo-recovery-*"))
+ os.lseek(source_fd, 0, os.SEEK_SET)
+ assert os.read(source_fd, 1024) == b"planned source"
+ finally:
+ original_close(source_fd)
+ original_close(root_fd)
+
+
+def test_recovery_fsyncs_file_before_anchored_root_directory(
+ monkeypatch: pytest.MonkeyPatch,
+ tmp_path: Path,
+) -> None:
+ if not file_organizer._supports_secure_directory_fds():
+ pytest.skip("secure directory descriptors are unavailable on this platform")
+
+ source = tmp_path / "notes.txt"
+ source.write_text("planned source", encoding="utf-8")
+ root_fd = file_organizer._open_source_directory_fd(tmp_path)
+ source_fd = os.open(source, os.O_RDONLY)
+ original_fsync = os.fsync
+ synced_fds: list[int] = []
+
+ def record_fsync(fd: int) -> None:
+ synced_fds.append(fd)
+ original_fsync(fd)
+
+ monkeypatch.setattr(file_organizer.os, "fsync", record_fsync)
+
+ try:
+ recovery_name = file_organizer._recover_pinned_source_at(
+ source_fd,
+ source.name,
+ root_fd=root_fd,
+ )
+
+ assert len(synced_fds) == 2
+ assert synced_fds[0] != root_fd
+ assert synced_fds[1] == root_fd
+ assert (tmp_path / recovery_name).read_text(
+ encoding="utf-8"
+ ) == "planned source"
+ finally:
+ os.close(source_fd)
+ os.close(root_fd)
+
+
def test_execute_plan_never_replaces_destination_created_after_preflight(
monkeypatch: pytest.MonkeyPatch,
tmp_path: Path, |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2230379bcc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex address that feedback Please address only the currently open Full Review 16 P2, |
Summary
Testing
|
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🏁 Historical Record: Phase 10 File OrganizerThis comment records the review history of PR #82 — Add Phase 10 File Organizer, which became the longest and most intensively reviewed pull request we have worked through in this repository so far. Timeline
Final PR numbers
The final diff numbers do not include all historical churn. Many lines were written, removed, rewritten, and hardened again across the 117 commits, so the actual amount of engineering change during the review loop was substantially larger than the final +4,186 / -36 diff. Final validation gateRepository quality checks #694: GREEN Ubuntu
Windows Server 2025
What this project becameWhat began as a deterministic File Organizer evolved into a much deeper filesystem-engineering exercise involving:
Several review findings exposed race windows that only became visible after earlier fixes had strengthened the surrounding state machine. Each finding was analyzed, corrected, covered by a focused regression where appropriate, validated by CI, and then subjected to another full review. Final milestoneAfter 117 commits, 17 review cycles, 27 addressed findings, 131 workflow runs, and approximately 20 hours of active engineering/review work, the final Codex verdict on
Phase 10, Step 5 — File Organizer: REVIEW COMPLETE. 🐍🏁 This PR is officially recorded as our longest review marathon in the Python Study Guide to date. |
1 participant
Summary
Project 06: File Organizer adds a deterministic, collision-aware filesystem workflow for direct child files, with planning separated from mutation and explicit Linux/Windows concurrency boundaries.
Implemented
OrganizationPlanas pathname/category intent, not a live filesystem-object snapshotERROR/SKIPcollision policies with exact + casefold checks.fo-stage-*/.fo-recovery-*internal namespacesfstat()on already-open source FDsO_NOFOLLOW | O_NONBLOCKsource pinning and explicit readability prerequisite for recoveryrenameat2(RENAME_NOREPLACE)on Linux.fo-recovery-*fallbackfsync(recovery_fd)followed byfsync(root_fd)so the new recovery directory entry is crash-durableIdentity boundary
OrganizationPlandeliberately records pathname/category intent. It does not keep live source descriptors or promise that a pathname still names the identical filesystem object observed during planning.If a regular file is replaced at the same planned pathname before
execute_plan()begins source binding, the current regular file at that pathname is selected. Strong object identity begins at execution-time pinning. On Linux, changes after that binding are rejected or conservatively recovered under the descriptor-based race contract.Deliberate scope
Descriptor pinning stabilizes Linux filesystem-object identity, not file-content snapshots. Concurrent writes to the same inode, recursive organization, MIME inspection, duplicate auto-renaming, hashing/deduplication, cross-filesystem moves, whole-plan transactions, watchers, deletion, GUI, and cloud storage remain out of scope.
Validation status
Repository quality checks #694 passed on clean current HEAD
ba72ac54e220e63b0ec6c88ac187f9fe26361109.Ubuntu / repository gate
Windows / File Organizer gate
The PR contains only the 22 intended project/documentation/CI files. The Review 16 correction is documentation-only: compared with reviewed HEAD
2230379bcc797300b24df2e30cfa05201b04a0a3, the final net change is exactly 1 line replaced in each of the EN / PT-BR / ES Project 06 READMEs. No implementation code, tests, workflow files, or unrelated documentation changed in that patch.Codex review history
Reviews 1–10
Addressed findings included missing learning chapters/navigation, late destination overwrite, category/source symlink races, unsafe rollback/unlink windows, stale test-count docs, root/category anchor races,
NAME_MAXstaging, FIFO blocking, late casefold collisions, staging replacement/data recovery, readability contract, FD cleanup, Windows junctions, and immediate inode reuse.Full Review 11
OrganizationPlanas pathname/category intent and binding strong source identity at execution-time descriptor pinning; regression coverage added.Full Review 12
.fo-recovery-*; added a regression for stage replacement + late exact destination + failed final rename.Full Review 13
Full Review 14
fsync()alone._recover_pinned_source_at()captures the created recovery inode identity from the open recovery FD, then re-reads the.fo-recovery-*pathname through the anchored root and requires the same regular-file(st_dev, st_ino)before returning its name.test_recovery_path_removed_during_fsync_is_not_reported_as_retained.Full Review 15
recovery_fdis closed. A regression removes the recovery pathname immediately after descriptor close and verifies that retention is not falsely reported.fsync(root_fd). A regression requires the exactrecovery -> rootsync order.Full Review 16
All submitted inline findings through Full Review 16 are addressed and resolved. Review 16 is green in CI #694.
Final gate
ba72ac54e220e63b0ec6c88ac187f9fe26361109Branch
phase-10-file-organizer