Skip to content

fix(file-manager): Mehrfach-Verschieben bricht nach dem ersten Eintrag nicht mehr ab - #542

Merged
iret77 merged 1 commit into
mainfrom
fix/fm-move-guard-pending-sources
Oct 10, 2026
Merged

iret77 merged 1 commit into
mainfrom
fix/fm-move-guard-pending-sources

Conversation

@iret77

@iret77 iret77 commented Oct 10, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

Der CI-Batch auf main (7982fdf07) ist bis auf einen Test grün (5339/5340). Rot ist nur f5_and_f6_transfer_marked_folders_and_files: F6 mit einem markierten Ordner und einer markierten Datei verschiebt nur den Ordner, die Datei bleibt liegen.

Ursache ist transfer_guard_is_current. Vor jedem Eintrag einer Copy/Move-Charge prüft der Guard, ob alle ursprünglich markierten Quellen noch in der Liste stehen. Ein abgeschlossener Move entfernt aber seine Quelle, sobald das Verzeichnis neu geladen wird. Danach gilt der Rest derselben Charge als veraltet und wird mit „anderer Pane getrennt“ verworfen. Beim Kopieren bleiben die Quellen stehen, deshalb fällt das dort nicht auf.

Das ist nicht nur ein Testartefakt. In der App tritt der Fehler auf, sobald mitten in einer Mehrfach-Verschiebung ein Konflikt-Dialog erscheint. Bis zur Antwort sind die vorherigen Moves fertig, und die Antwort wird dann verworfen.

Den Guard gibt es seit dem 21.09., den Test seit der Mehrfachmarkierung vom 06.10. Seitdem ist kein Batch bis zu den Tests gekommen.

Änderung

  • TransferRouteGuard::release_source: Ist die Charge mit einer Quelle fertig (übergeben, übersprungen oder Prüffehler), muss diese nicht mehr in der Liste stehen. Geprüft werden nur noch die offenen Einträge.
  • Aufgerufen wird es an allen Stellen, an denen ein Eintrag die Charge verlässt: execute_copy_move_op, Skip in der Schleife, Prüffehler, Skip im Konflikt-Dialog.
  • Die übrigen Prüfungen bleiben unverändert: Quell- und Ziel-Pane registriert, Backend vorhanden, Pane-Identität gleich. same_fs_conflict_confirmation_rejects_a_closed_target_before_queue_submission deckt das weiter ab.
  • Neuer Regressionstest f6_batch_reaches_conflict_prompt_after_an_earlier_item_moved: a.txt wird verschoben, danach erreicht b.txt trotzdem seinen Konflikt-Dialog.

Nicht enthalten (Folgeaufgabe)

Im Cross-Connection-Pfad (finish_cross_connection_preparation → resolve_cross_conn_conflict) steckt dasselbe Muster. Nicht-konfliktbehaftete Dateien starten sofort, und die spätere Konflikt-Auflösung prüft wieder alle ursprünglichen Quellen. Das ist hier bewusst nicht mitgefixt, weil es im CI-Reparatur-PR ohne eigenen Test wäre.

Verifikation

Lokal nicht gebaut, nur rustfmt --check. Bestätigt wird das erst durch den nächsten ci-batch auf main.

🤖 Generated with Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

…g nicht mehr ab

Der Transfer-Guard verlangte, dass alle ursprünglich markierten Quellen
noch in der Liste stehen. Ein abgeschlossener Move entfernt seine Quelle
aber beim Neuladen des Verzeichnisses, sodass der Rest derselben Charge als
veraltet verworfen wurde ("anderer Pane getrennt"). Der Guard gibt eine
Quelle jetzt frei, sobald die Charge mit ihr fertig ist (übergeben,
übersprungen oder Prüffehler), und prüft nur noch die offenen Einträge.

Betrifft F6 mit mehreren markierten Einträgen, in der App vor allem dann,
wenn mitten in der Charge ein Konflikt-Dialog erscheint. Neuer
Regressionstest für genau diesen Fall.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@iret77
iret77 merged commit 7ab80ee into main Oct 10, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant