KIO in KDE Frameworks 6.32: USB-Kopien melden erst nach dem Schreiben Erfolg

Mit KDE Frameworks 6.32 vom 13. November 2026 meldet KIO, die Dateischicht hinter Dolphin und anderen KDE-Programmen, Kopien auf USB-Sticks erst dann als fertig, wenn die Daten tatsächlich auf dem Gerät liegen. Die neue Logik greift nur bei Wechseldatenträgern und langsamen Netzwerk-Mounts, lokale Festplatten kopieren wie bisher. Das geht aus der Release-Ankündigung des KDE-Projekts und einem Blogbeitrag von Entwickler Méven Car vom 27. Oktober 2026 hervor. Die Pakete liefern die Distributionen über ihre stabilen Repositorien aus.

Warum KIO fünfzehn Jahre lang zu früh „fertig“ meldete

KIO hat Kopien auf USB-Sticks bis zur Vorversion als abgeschlossen gemeldet, während ein Teil der Daten noch im Arbeitsspeicher lag. In Bug 281270 beschreiben Betroffene seit 2011 immer wieder dasselbe Muster. Dolphin zeigt 100 Prozent. Die LED am Stick blinkt weiter. Das sichere Entfernen zieht sich danach hin, in einem Kommentar von 2018 um rund zwei Minuten.

Den Mechanismus erklärt Car in seinem Blogbeitrag zur Korrektur im KDE-Blog. Der Datei-Worker, ein eigener Prozess für den Kopiervorgang, übergibt die Daten an den Systemaufruf write(). Dieser Aufruf kehrt zurück, sobald die Daten im Page Cache liegen, dem Schreibpuffer des Kernels im RAM. Auf das Gerät schreibt der Kernel später. Auf einer lokalen SSD fällt der Verzug nicht auf.

Langsame Ziele machen aus dem Verzug ein Risiko. Laut Car hielt Dolphin eine 128 MiB große Datei auf einem USB-2.0-Stick mit 2,3 MB/s länger als eine Minute für fertig kopiert, während der Stick noch schrieb. Wer ihn in dieser Zeit abzieht, verliert die Daten. Der erste Bericht vom 3. September 2011, damals gegen KDE 4.7, nannte rund 50 MB/s für ein USB-1.1-Gerät. Ein solches Gerät schafft laut Car höchstens 12 Mbit/s.

Netzwerkfreigaben zeigen ein anderes Symptom derselben Ursache. Bei großen Kopien auf NFS- oder SMB-Shares bleiben laut Car Hunderte MiB im Speicher, und der Fortschritt eilt dem Server weit voraus. Unter SMB kommt die Standardoption cache=strict hinzu. Mit ihr wartet jeder Blick auf eine Datei, bis deren ungeschriebene Daten beim Server angekommen sind. Über eine Leitung mit 5 MB/s hingen Verzeichnislistings während einer 1 GiB großen Kopie deshalb 15 bis 20 Sekunden.

Fünfzehn Jahre Bugreport für einen einzigen Systemaufruf

Der Systemaufruf sync_file_range(), mit dem KIO das Problem jetzt löst, stand schon im September 2011 im Bugreport. Zwei Tage nach der Meldung fragte KDE-Entwickler Christoph Feck nach einem Weg, den echten Schreibstand zu erfahren, ohne alles mit sync-Aufrufen auszubremsen. Der Melder leitete laut Bugreport die Antwort von Kernel-Entwickler Alan Stern weiter. Sie lautete sync_file_range(). Feck sah darin genau das, was KDE brauchte. Danach ruhte die Sache.

Bewegung kam in Etappen. Nate Graham stufte den Fehler im September 2021 als kritisch ein, weil ein Verschieben die Quelldateien löscht, während die Kopien noch im Speicher stehen. 2022 änderte er das Applet „Disks & Devices“, damit es beim Auswerfen auf laufende Schreibvorgänge hinweist. 2024 testete Feck den Aufruf cachestat() aus Linux 6.5, der allerdings nur je Datei meldet, wie viel noch ungeschrieben ist. Car selbst scheiterte 2024 zweimal. Sein Worker wartete auf den gerade geschriebenen Abschnitt, dessen Rückschreiben noch gar nicht begonnen hatte.

Eine korrekte Kopie allein wäre laut Car einfach gewesen. Ein fsync() nach jeder Datei oder das Öffnen des Ziels mit O_DIRECT, also am Cache vorbei, liefert exakte Zahlen. Beide Wege machen Kopien aber um ein Mehrfaches langsamer, auch auf schnellen lokalen Platten ohne jedes Problem. Der Aufruf sync_file_range() existiert nur unter Linux, und seine Manpage nennt ihn „extremely dangerous“. Er schreibt keine Metadaten. Am Ende einer Kopie bleibt deshalb ein echter Flush nötig.

Zusätzlich brauchte KIO eine billige Auskunft darüber, welches Ziel überhaupt langsam ist. Zwei Umbauten an KMountPoint, der Mount-Verwaltung von KIO, lieferten sie. Merge Request 2326, also ein Änderungsantrag im KDE-GitLab, speichert seit KIO 6.30 Mounts nach der Mount-ID, die statx() seit Linux 6.8 liefert. Die Suche wurde dadurch laut Car etwa 700-mal schneller. Merge Request 2487 in KIO 6.32 liest fehlende Mounts mit statmount(), sodass ein schweigender Server die Abfrage nicht mehr blockiert. Statt mehr als 15 Sekunden dauert sie dann etwa 1 ms. Aktuelle Reihen wie Linux 7.3 mit seinen Dateisystem-Änderungen liegen weit über dieser Kernel-Schwelle.

Schreibfenster statt fsync nach jeder Datei

KIO schreibt Kopien auf langsame Ziele seit Frameworks 6.32 in Fenstern, also in Datenblöcken, deren Rückschreiben auf das Gerät der Worker gezielt anstößt und abwartet. Ist ein Fenster voll, übergibt es der Worker an einen Hilfsthread, der sync_file_range() aufruft und wartet. Die Kopie füllt währenddessen das nächste Fenster. Sie pausiert nur, wenn das vorherige Fenster noch nicht auf dem Gerät ist.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9PromptPhotorealistic editorial photo: low-angle close-up of a black USB flash drive plugged into the side port of a silver laptop on a light wooden desk, its activity LED glowing softly. Behind it, out of focus, a monitor shows a generic Linux KDE Plasma desktop with a file manager window and a copy progress bar partly filled, rendered in calm blue and white tones, with no readable numbers and no operating system logos. The laptop keyboard is only seen from the side and strongly blurred, with no legible key labels. Soft natural daylight from a window on the left, shallow depth of field, neutral color palette with subtle blue accents, clean and sharp magazine look. No people, no hands. No watermark, no signature.

Laut Car liegen höchstens zwei Fenster einer Kopie im Speicher, ohne schon auf dem Gerät zu sein. Der Fortschrittsbalken eilt dem tatsächlich Geschriebenen damit höchstens um ein Fenster voraus. Die Größe passt sich an die gemessene Geschwindigkeit des vorigen Fensters an. Ein Fenster darf sich je Schritt höchstens verdoppeln und bleibt unter 16 MiB. Auf schnellen Leitungen wachsen die Fenster, auf langsamen bleiben sie bei rund 1 MiB. Wer dann auf die Datei zugreift, wartet Sekundenbruchteile statt auf die ganze Datei.

Der Hilfsthread existiert wegen CIFS, dem Kernel-Client für Samba- und Windows-Freigaben. Dort sendet schon das Anstoßen des Rückschreibens die Daten an den Server und wartet auf dessen Freigabe. Car maß dabei eine Blockade von etwa 157 ms je 128 MiB großem Fenster. Mit dem Thread überlappen Senden und Füllen. Für CIFS liegt die Obergrenze deshalb bei 128 MiB.

Am Ende einer Kopie auf einen Wechseldatenträger wartet KIO zusätzlich, bis alles auf dem Gerät liegt. Dateien über 16 MiB bekommen ein fsync(), danach ihr Ordner. Für kleine Dateien wäre das zu teuer: 3000 Dateien zu je 16 KiB brauchten mit fsync() pro Datei auf einer lokalen Platte 10 Sekunden statt 0,04 Sekunden. Stattdessen schickt der CopyJob, der den gesamten Vorgang in der Anwendung steuert, einen letzten Befehl. Der Worker schreibt dann mit einem einzigen syncfs() das ganze Ziel-Dateisystem zurück. Die Benachrichtigung meldet währenddessen, dass die Daten auf das Gerät geschrieben werden. Scheitert dieser Flush, scheitert die Kopie.

Beim Verschieben auf Wechseldatenträger ändert sich am meisten. Bisher löschte KIO jede Quelldatei direkt nach ihrer Kopie, auch wenn diese erst im Speicher stand. Jetzt bleiben die Quellen erhalten, bis der Flush gelungen ist. Scheitert er oder verschwindet der Stick mittendrin, bleiben alle Quellen stehen. Hat sich eine Quelle während des Wartens geändert, bleibt sie ebenfalls, und KIO warnt. Bricht ein Verschieben ab, löscht es nur die Quellen der Dateien, die schon auf dem Gerät sind. Ältere Frameworks-Versionen haben diesen Schutz nicht. Backup zuerst.

Welche Ziele bekommen das neue Verhalten?

Lokale Festplatten behalten in KIO exakt das bisherige Kopierverhalten. Mit testweise erzwungener Wechseldatenträger-Logik auf einer lokalen Platte brauchten 3000 kleine Dateien laut Car 1,55 statt 1,54 Sekunden. Die folgende Tabelle zeigt, wie KIO die Zieltypen einordnet und was sich jeweils ändert.

Die Erkennung von Wechseldatenträgern ist kniffliger, als sie wirkt. Der Dateisystemtyp hilft kaum: exFAT kann auf einer Speicherkarte liegen, FAT ist auch die EFI-Partition des Notebooks. Die meisten USB-Platten melden laut Car nicht einmal ein Wechselmedium. Merge Request 2506 liest deshalb sysfs aus, die Kernel-Schnittstelle unter /sys. Neben dem Flag der Platte zählt dort der USB-Port oder PCIe-Slot, den der Kernel als von außen erreichbar markiert. Verschlüsselte und LVM-Volumes verfolgt die Funktion bis zur Platte darunter.

Auf Netzwerkfreigaben fallen die Messwerte gemischt, aber vertretbar aus. Car testete gegen einen SMB-Server auf derselben Maschine mit 2 ms künstlicher Verzögerung, für die langsame Variante zusätzlich auf 40 Mbit/s begrenzt. Dort lief die Kopie etwa 3 Prozent langsamer. Ein komplettes Listing des Zielordners dauerte dafür 1,7 Sekunden statt 5 bis 11 Sekunden. Ein früherer Ansatz mit Fenstern von 500 ms trieb die Listings noch auf 4,2 Sekunden. Unter NFS war die Kopie in einer Runde 11 Prozent langsamer, in zwei weiteren leicht schneller.

Die Grenze zwischen Desktop und Server verläuft klar. KIO arbeitet in Dolphin, in KDE-Dateidialogen und anderen KDE-Anwendungen, also auf dem Client. Der Server, der eine SMB- oder NFS-Freigabe bereitstellt, braucht für die Korrektur kein Update. Headless-Systeme ohne KDE-Software betrifft sie nicht. Auch cp und rsync nutzen KIO nicht. Im Terminal kehrt der Prompt nach einer Kopie auf einen Stick weiterhin zurück, bevor der Kernel alles geschrieben hat. Erst ein anschließendes sync wartet darauf.

Für solche Fälle beschreibt ein Kommentar im Bugreport vom Januar 2025 eine udev-Regel, die den Schreibcache je USB-Gerät auf 16 MB begrenzt. Für Dolphin wird der Umweg mit 6.32 entbehrlich, auf der Kommandozeile bleibt er eine saubere Option.

Was Frameworks 6.32 sonst repariert und wann es ankommt

KDE Frameworks 6.32 beschleunigt Kopien zwischen zwei Dateisystemen, unabhängig vom Zieltyp. Car hatte 2021 in Frameworks 5.88 sendfile() durch copy_file_range() ersetzt. Seit Linux 5.19 schlägt copy_file_range() zwischen verschiedenen Dateisystemen jedoch wieder mit EXDEV fehl. Der Worker fiel dann auf read() und write() zurück, Puffer für Puffer. Merge Request 2520 nutzt in diesem Fall wieder sendfile(), das innerhalb des Kernels kopiert. Laut Release-Ankündigung richtet KIO die Aufrufe von copy_file_range() zudem auf 8 MiB aus.

Laut 9to5Linux bringt die Ausgabe weitere Korrekturen für den Plasma-Alltag:

• Ein Hänger ist behoben, wenn eine manuell eingebundene Netzwerkfreigabe im Orte-Bereich nicht mehr erreichbar ist.
• Horizontales Scrollen per Alt + Mausrad funktioniert wieder, nachdem eine Anpassung an Qt 6.12 es gebrochen hatte.
• Bei gebrochenen Skalierungsfaktoren wirken Symbole in Plasma und Kirigami-Apps weniger unscharf und zappeln beim Ändern der Fenstergröße weniger.
• Der gemeinsame SVG-Code von Plasma und vielen KDE-Apps liest Grafiken schneller.
• Der KWallet-Assistent rät bei fehlender PAM-Einrichtung zu einer Blowfish-Wallet und erklärt GPG, wenn keine Schlüssel vorhanden sind.
• Qt-Apps mit Unschärfeeffekt stürzen nicht mehr ab, wenn beim Tippen ein Tooltip verschwindet.

Frameworks erscheinen in einem monatlichen Release-Zyklus, wie die Release-Ankündigung vom 13. November 2026 festhält. Zuletzt hatte etwa KDE Frameworks 6.29 in den Bibliotheken aufgeräumt. 9to5Linux beziffert die Sammlung auf mehr als 80 Zusatzbibliotheken zu Qt und rät zu einem zügigen Update. Upstream ist die Arbeit damit erledigt, der Rest liegt bei den Paketierenden. Rolling-Release-Distributionen wie Artix, das Plasma inzwischen ohne systemd unter Wayland anbietet, ziehen meist früher nach. Welche Version läuft, zeigt das Info-Center von Plasma auf seiner Übersichtsseite. Bis 6.32 installiert ist, gilt die alte Regel. Erst auswerfen, dann ziehen.

Bug 281270 trägt im KDE-Bugtracker inzwischen den Status „Resolved Fixed“, als Korrekturversion steht 6.32. Offen bleibt der Sammelbug 423187 zu Dolphin-Hängern auf langsamen Mounts. Das Schreibfenster entschärft dort Listings, die hinter wartenden Uploads stehen. Wartezeiten im Hauptthread von Dolphin sind laut Car nur teilweise behoben, auf Linux 6.8 oder neuer etwa beim Erkennen langsamer Dateien. Den Rest sollen die noch offenen Merge Requests 2484 und 2485 von Frank Gehann erledigen.