Repository navigation
ExplorerPro 1.0.9: CrossDevice-Download lädt lange; Zurück ist zeitweise nicht bedienbar #27
Description
Umgebung
- Gemeldeter Stand: ExplorerPro 1.0.9
- Konkreter Ordner: %USERPROFILE%\CrossDevice\Pixel 8a\storage\Download
- Vermutung: Smartphone-synchronisierter oder anderweitig über CrossDevice bereitgestellter Speicher. Die konkrete Transport-/Providerart ist nicht bestätigt.
Beobachtung
Der Fehler wurde beim Öffnen eines großen beziehungsweise Netzwerkordners gemeldet. Im konkreten CrossDevice-Download-Ordner wirkte ExplorerPro zunächst festgefahren; währenddessen ließ sich der Zurück-Pfeil zeitweise nicht benutzen. Nach längerer Wartezeit öffnete sich der Ordner doch, und ExplorerPro stabilisierte sich anschließend. Ein dauerhafter Absturz ist für diesen konkreten Versuch nicht bestätigt.
Ladezeit, Dateianzahl, Windows-Build und Verbindungsart wurden nicht gemessen.
Bezug zu den bereits gemergten 1.0.9-Fixes
Das Verhalten überschneidet sich mit den bereits in 1.0.9 enthaltenen Arbeiten:
- PR #21: langsame Laufwerke, asynchrone Dateisystemabfragen, Ladehinweis und zuletzt bekannte Einträge.
- PR #23: asynchrone Laufwerksprüfung, bedienbare alte Ansicht, vorgewärmte Laufwerkswurzeln und QFileSystemModel.fetchMore.
- PR #24: Status und Zurück-Verhalten bei nicht erreichbaren Laufwerken sowie Anzeige vorgehaltener Daten.
- PR #25: verspätete Ergebnisse dürfen eine inzwischen gewählte Ansicht nicht überschreiben.
Bitte prüfen, ob die Enumeration eines großen CrossDevice-/Smartphone-Ordners diese Pfade umgeht oder ob hier eine Lücke beziehungsweise Regression in den vorhandenen Lade- und Navigationspfaden besteht. Insbesondere wäre zu prüfen, ob Provider- oder Verzeichnisabfragen trotz der Worker noch den GUI-Thread beziehungsweise die Zurück-Navigation blockieren.
Erwartetes Verhalten / mögliche Prüfpunkte
- Die Oberfläche und Zurück-/Ordnernavigation bleiben während der Enumeration sofort bedienbar.
- Zunächst sichtbare oder benötigte Einträge werden in begrenzten Schritten geladen; weitere Einträge folgen bei Bedarf, mit Zeit für die Qt-Ereignisschleife zwischen den Batches.
- Ein klarer Status wie „Ordner wird im Hintergrund geladen – du kannst weiterarbeiten“ zeigt den laufenden Vorgang.
- Beim Wechsel in einen anderen Ordner kann der Ladevorgang weiterlaufen oder bereits geladene Teilergebnisse zwischenspeichern. Bei der Rückkehr werden diese sofort angezeigt und anschließend aktualisiert.
- Verspätete Ergebnisse dürfen die aktuell ausgewählte Ansicht nicht ersetzen. Dateisystem-/Provider-Aufrufe bleiben vom GUI-Thread getrennt; falls ein Provider-Aufruf einen Worker unbeschränkt blockieren kann, sollte eine isolierte, kontrollierbare Ausführung geprüft werden.
Ein Regressionstest mit verzögerter beziehungsweise großer Verzeichnisauflistung sollte GUI-Reaktionsfähigkeit, sofortiges Zurücknavigieren, gestaffelte Ergebnisse und das Wiederanzeigen vorgeladener Inhalte abdecken.
Noch offene Reproduktionsdaten
Falls der Fehler erneut auftritt, wären Dauer bis zur ersten Anzeige, ungefähre Dateianzahl, Windows-Build und die tatsächliche Verbindung (z. B. MTP/Phone-Link, SMB oder anderer CrossDevice-Provider) hilfreich.
Activity
github-actions commentedon Oct 14, 2026
Welcome! Thanks for opening your first issue in this repository.
We'll review it as soon as possible. In the meantime:
If you'd like to contribute a fix, PRs are welcome.
lukisch commentedon Oct 24, 2026
Triage (Zweitmodell): Bug, Priorität Medium (Bedienbarkeit, keine Datenverluste). Die Symptome (lange Ladezeit beim CrossDevice-Download, "Zurück" zeitweise blockiert) passen zu GUI-Thread-Blockaden. Zwei offene Draft-PRs adressieren das bereits: #28 (Provider-Klicks außerhalb des GUI-Threads klassifizieren) und #30 (Sidebar-Ordner gestreamt/gecacht in begrenzten GUI-Batches), dazu #29 (Test-Isolation der Capacity-Worker). Vorschlag: nach Merge von #28/#30 den Fall mit 1.0.9 nachstellen und dann schließen.
Generated by Claude Code
lukisch commentedon Nov 3, 2026
Triage: Bug, Priorität Medium. Teilweise bereits durch PR #21/#23 (1.0.9) abgedeckt. Offen bleibt die Frage, ob die Ordner-Listung im CrossDevice-Pfad weiterhin den GUI-Thread blockiert. Die offenen PRs #28 (Klassifizierung außerhalb des GUI-Threads), #29 und #30 (Sidebar-Streaming mit begrenzten GUI-Batches) zielen darauf. Empfehlung: nach deren Merge mit einem großen Netzwerk-/CrossDevice-Ordner erneut messen (Dateianzahl, Ladezeit) und das Issue dann schließen oder mit Messwerten präzisieren. Keine Duplikate gefunden.
Generated by Claude Code
ellmos-multi-bot commentedon Nov 3, 2026
Quellenstand nach unabhängiger Abnahme (03.11.2026, Codex):
Die ursprüngliche Fehlermeldung ist damit nicht vollständig abgenommen. Eine echte CrossDevice-Reproduktion samt Dateianzahl, Ladezeit und bedienbarer Zurück-Navigation fehlt weiterhin. #30 ist noch Draft; Sidebar-Streaming/Caching, vollständige Dateitabellen-Paginierung und begrenzte Provider-Worker-Lebensdauer sind getrennte offene Prüfpunkte. Keine Geräte-, Store- oder Releaseabnahme.
Korrektur des Issuezustands: GitHubs ClosedEvent nennt PR #29 als Closer (closedAt 12:50:25Z). Das automatische Schließen beim Merge war unbeabsichtigt und ist kein Beleg für eine vollständige Fehlerbehebung. Der negierte PR-Text enthält eine schließende Issue-Referenz; diese wurde bei der Abnahme übersehen. Die Offenhaltung wurde faktisch nicht erreicht. Die Wiederöffnung ist erforderlich und wurde in diesem Lauf noch nicht ausgeführt.