You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: TODO.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,8 +30,17 @@
30
30
-[x] ROADMAP.md (langfristige Planung)
31
31
-[x] PORTIERUNGSPLAN.md (Linux/macOS)
32
32
33
+
## Erkenntnisse aus MCP-Integration (2026-05-31)
34
+
35
+
Beim Port der copy+delete-Logik in den ellmos-filecommander-mcp-Server (TypeScript) wurden folgende Punkte entdeckt:
36
+
37
+
-[ ]**EBUSY als Fehlercode aufnehmen:** Windows gibt bei File-Locks durch andere Prozesse (inkl. Cloud-Sync) `EBUSY` zurück, nicht nur EPERM/EACCES. CLFs `ops.py` sollte EBUSY in die Retry-Trigger-Codes aufnehmen (aktuell nur EXDEV + Access Denied).
38
+
-[ ]**Delete-nach-Copy bei aktivem Lock:** Wenn die Kopie erfolgreich ist aber das Löschen des Originals mit EBUSY scheitert (Datei noch vom Sync-Client gehalten), ist das ein Teilerfolg. CLF handhabt das bereits via Queue-Retry — aber der Status sollte explizit als "kopiert, Löschung ausstehend" im queue.txt sichtbar sein.
39
+
-[ ]**Verzeichnis-Rename mit gelockter Innendatei:** Bei `fs.rename()` auf ein Verzeichnis, dessen Inhalt einen gelockten File enthält, gibt Windows EPERM (nicht EBUSY). Die copy+delete-Strategie funktioniert hier korrekt (rekursives Kopieren + rekursives Löschen), aber das Löschen des Quellverzeichnisses scheitert wenn eine Innendatei noch gelockt ist. CLFs `ops.py` sollte diesen Fall explizit behandeln.
40
+
33
41
## Nächste Schritte (aus ROADMAP.md)
34
42
43
+
-[ ] Test-CI beobachten und bei Bedarf Windows-spezifische Runtime-Abhängigkeiten ergänzen
0 commit comments