RcloneView 1.6 – Release Notes

Veröffentlichungsdatum: Oktober 2026
Plattformen: Windows, macOS, Linux

RcloneView 1.6 ist ein Korrektheits-Release. Zwei Wege, auf denen Dateien verloren gehen konnten, und ein offener Netzwerkport wurden geschlossen, die Flags, die Sie in einen Job eingeben, werden jetzt tatsächlich an rclone übergeben, eine fehlgeschlagene Synchronisation kann sich nicht mehr selbst als abgeschlossen melden, und RcloneView beendet keine rclone-Prozesse mehr, die nicht zu ihm gehören. Spätere 1.6-Updates verhindern außerdem, dass sich ein Remote mit falschem Passwort immer wieder anmeldet, bis der Server diesen Computer sperrt, und dass geplante Jobs einmal für jedes geöffnete Fenster ausgeführt werden. Darüber hinaus behebt dieses Release eine lange Liste von Problemen bei Mounts, im Explorer, beim Erstellen von Remotes, im Assistenten und bei der Paketierung auf allen drei Plattformen.

Bitte vor dem Upgrade lesen

• Filter-Flags in den benutzerdefinierten Flags eines Jobs wirken jetzt. Filter-Flags wie --include, --exclude und --filter, die in das Feld Benutzerdefinierte Flags eines Jobs eingegeben wurden, gingen verloren, bevor der Job lief – sie galten nur bei einem Probelauf und bei der Bisync-Diagnose, sodass Vorschau und tatsächlicher Lauf voneinander abweichen konnten. Jetzt werden sie auf jedem Weg weitergegeben.
  Dadurch ändert sich das Verhalten bestehender Jobs. Wenn Sie einen Job mit Filtern in den benutzerdefinierten Flags haben, überträgt er jetzt nur noch die passenden Dateien statt aller. Bei einem Job vom Typ Synchronisieren mit aktiviertem Löschen ändert sich dadurch auch, was am Ziel gelöscht wird. Bitte prüfen Sie jeden Job, der Filter in den benutzerdefinierten Flags enthält, und führen Sie ihn einmal mit Probelauf aus, bevor Sie ihn nach Zeitplan laufen lassen.

• Bei einem Remote, dessen Passwort ein langes Token ist, muss das Passwort noch einmal eingegeben werden. Beim Speichern eines Remotes überließ RcloneView es rclone, selbst zu entscheiden, ob das übergebene Passwort noch kodiert werden muss. Bei einem Passwort, das wie Base64 aussieht, ist diese Vermutung immer falsch, sodass der Wert unkodiert in die Konfiguration geschrieben und bei jedem Verbindungsversuch verfälscht wurde. Ein auf diese Weise gespeichertes Remote konnte sich nie authentifizieren. RcloneView kodiert Passwörter jetzt selbst, sodass alles, was Sie ab dieser Version hinzufügen oder bearbeiten, korrekt gespeichert wird.
  Bereits auf diese Weise gespeicherte Remotes werden durch das Update nicht repariert. Betroffen ist nur ein Passwort mit mindestens 22 Zeichen, das ausschließlich aus Buchstaben, Ziffern, - und _ besteht – in der Praxis ein API-Token oder ein generiertes App-Passwort, nicht eines, das Sie selbst gewählt haben. Wenn ein Remote mit einem Authentifizierungsfehler keine Verbindung herstellen konnte, öffnen Sie es unter Remote-Manager → Bearbeiten, geben Sie das Passwort erneut ein und speichern Sie. Danach verbindet es sich.
  Geben Sie das Passwort eines Crypt-Remotes, das heute korrekt geöffnet wird, nicht erneut ein. Ein auf diese Weise gespeichertes Crypt-Remote ist nie fehlgeschlagen: Seine Dateien wurden mit dem verfälschten Wert verschlüsselt, und nur dieser Wert liest sie wieder aus. Würden Sie jetzt das echte Passwort eingeben, würde das Remote auf einen anderen Schlüssel umgestellt, und die darin bereits vorhandenen Dateien ließen sich nicht mehr öffnen. Lassen Sie ein solches Remote unverändert – das Bearbeiten seiner übrigen Einstellungen ist unbedenklich. Wenn Sie das Passwort bereits erneut eingegeben haben und sich die Dateien nicht mehr öffnen lassen, tragen Sie den alten Wert wieder in rclone.conf ein: Es war das Passwort selbst, ohne Kodierung geschrieben. Um ein solches Remote auf sein echtes Passwort umzustellen, kopieren Sie die Dateien zuerst über das bestehende Remote heraus und legen das Remote dann neu an.

• Bei aktivierter App-Sperre startet nichts, bevor die App entsperrt ist. Der Sperrbildschirm erscheint jetzt vor jedem Fensterinhalt, und rclone, geplante Jobs, automatische Mounts und der Webserver warten auf das Passwort, statt hinter dem Sperrbildschirm zu starten. Wenn RcloneView bei der Anmeldung mit aktivierter App-Sperre startet, werden geplante Jobs und automatische Mounts erst ausgeführt, wenn jemand die App entsperrt. Wenn sich dieser Computer darauf verlässt, dass Jobs oder Mounts nach einem Neustart unbeaufsichtigt laufen, deaktivieren Sie die App-Sperre oder entsperren Sie die App nach jeder Anmeldung.

• Ein Remote, dessen Anmeldung abgelehnt wird, wird nicht mehr automatisch kontaktiert. Bei Remotes, die sich mit einem Passwort anmelden – SFTP, FTP, WebDAV und SMB –, prüft RcloneView die Anmeldung jetzt einmal und stellt die Verbindung zu diesem Remote ein, wenn der Server sie ablehnt: kein automatischer Mount, kein geplanter Job, kein erneutes Öffnen seiner Tabs. Das bleibt über Neustarts hinweg gespeichert. Ein geplanter Job, der ein solches Remote verwendet, wird als fehlgeschlagen verzeichnet und löst die übliche Fehlerbenachrichtigung aus. Die Verbindung wird wieder aufgenommen, sobald Sie im Explorer auf Erneut versuchen klicken oder in Remote bearbeiten das korrigierte Passwort speichern.
  Wenn ein Server die Anmeldung nur vorübergehend ablehnt – zum Beispiel während sein Passwort geändert wird –, bleiben geplante Jobs auf diesem Remote danach pausiert, bis jemand auf Erneut versuchen klickt. Cloud-Speicher, bei denen Sie sich über einen Browser oder mit einem Schlüssel anmelden, sind nicht betroffen.

• Geplante Jobs laufen jetzt nur noch vom Hauptfenster aus. Zeitpläne folgen der rclone-Verbindung des Hauptfensters. Wenn Sie nur ein sekundäres Fenster auf eine andere Verbindung umgestellt haben, laufen die geplanten Jobs dieser Verbindung nicht mehr, solange dieses Fenster geöffnet ist; wählen Sie die Verbindung stattdessen im Hauptfenster aus. Wenn das Hauptfenster unerwartet geschlossen wird, stoppen die geplanten Jobs, bis RcloneView erneut gestartet wird, auch wenn andere Fenster noch geöffnet sind.

Datenverlust und Sicherheit

• Erneut versuchen nach teilweise fehlgeschlagenem Löschen konnte den übergeordneten Ordner entfernen: Wenn Sie mehrere Dateien gleichzeitig löschten, einige davon fehlschlugen und Sie dann auf Erneut versuchen klickten, konnte der gesamte übergeordnete Ordner entfernt werden, statt die fehlgeschlagenen Dateien erneut zu versuchen. „Erneut versuchen“ wirkt jetzt nur noch auf die Elemente, die fehlgeschlagen sind.

• Dateinamen mit [ ] * ? { konnten die falschen Dateien löschen: Beim Löschen mehrerer Dateien wurden deren Pfade ohne Maskierung an die Filter-Engine von rclone übergeben, sodass ein Name mit einem Mustersonderzeichen wie ein Platzhalter behandelt wurde. Ein einzelnes Löschen konnte Dateien in anderen Ordnern treffen – und entfernen. Pfade werden jetzt maskiert, bevor sie als Filter verwendet werden.

• Das Erstellen eines Remotes unter einem vorhandenen Namen ersetzte dieses Remote: rclone behandelt „create“ als „create or update“, sodass das Erstellen eines Remotes mit einem bereits vergebenen Namen – selbst mit einem anderen Speichertyp – stillschweigend die Einstellungen und Zugangsdaten des vorhandenen Remotes überschrieb. Der Dialog „Neues Remote“, der Assistent und der Crypt-Schritt des Assistenten warnen jetzt, sobald Sie einen bereits vergebenen Namen eingeben, und fahren nicht fort.

• Der Port für die Kommunikation zwischen Fenstern war zum Netzwerk hin offen: Der Port, über den RcloneView zwischen seinen eigenen Fenstern kommuniziert (13542), lauschte auf allen Netzwerkschnittstellen statt nur auf diesem Rechner, und das Hauptfenster akzeptierte einen leeren Authentifizierungsschlüssel. Er bindet sich jetzt nur noch an den lokalen Rechner und verlangt einen echten Schlüssel.

Highlights

• RcloneView beendet Ihre anderen rclone-Prozesse nicht mehr: Beim Beenden der App, beim Neustart von rclone oder bei Rclone aktualisieren wurde rclone über seinen Namen beendet, wodurch auch jedes andere rclone auf dem Rechner beendet wurde – ein rclone mount, den Sie in einem Terminal gestartet hatten, ein Cron-Job oder ein anderes Tool, das rclone verwendet. RcloneView beendet jetzt nur noch den Prozess, den es selbst gestartet hat.

• Ein falsches Passwort führt nicht mehr zur Sperrung dieses Computers: Ein einziges SFTP-Remote mit falschem Passwort konnte sich dutzende Male anmelden, bis das NAS die IP-Adresse dieses Computers sperrte. rclone wiederholt eine abgelehnte Anmeldung bis zu zehnmal pro Anfrage, das Öffnen eines einzelnen Tabs löste mehrere Anfragen gleichzeitig aus, und die App wiederholte eine fehlgeschlagene Auflistung noch dreimal – rund 80 Anmeldungen für einen Tab. Außerdem verband sich die App von selbst beim Start, beim Wiederherstellen von Tabs, für automatische Mounts und für geplante Jobs. Bei Remotes, die sich mit einem Passwort anmelden (SFTP, FTP, WebDAV, SMB), prüft RcloneView die Anmeldung jetzt einmal und hört auf, wenn sie abgelehnt wird. Der Explorer zeigt Anmeldung fehlgeschlagen mit den Schaltflächen Remote bearbeiten und Erneut versuchen – bei einem Crypt- oder Alias-Remote verweist er auf das darunterliegende Remote –, und der Remote-Manager zeigt statt des freien Speicherplatzes ein Abzeichen Anmeldung fehlgeschlagen. Ein Remote, das in Neues Remote mit falschem Passwort hinzugefügt wird, wird nicht gespeichert. Wenn ein Server nach wiederholten Fehlschlägen nicht mehr antwortet, meldet der Explorer jetzt innerhalb von Sekunden, dass die IP möglicherweise gesperrt wurde, statt etwa 50 Sekunden lang eine Ladeanzeige zu zeigen.

• Geplante Jobs liefen einmal für jedes geöffnete Fenster: Jedes RcloneView-Fenster führte seinen eigenen Scheduler aus, sodass bei einem zweiten geöffneten Fenster jeder geplante Job und jeder Batch pro Fenster zum selben Zeitpunkt einmal gestartet wurde. Zwei Kopien, die in denselben lokalen Ordner schrieben, löschten gegenseitig ihre unvollständigen Dateien, und der Lauf konnte enden, ohne dass etwas kopiert wurde. Das Ändern oder Löschen eines Zeitplans in einem sekundären Fenster ließ außerdem das Hauptfenster weiter den alten Zeitplan auslösen. Zeitpläne laufen jetzt nur noch vom Hauptfenster aus, und in anderen Fenstern vorgenommene Änderungen werden an dieses weitergegeben. Wenn Sie genau in dem Moment, in dem ein Zeitplan ausgelöst wurde, auf Ausführen klickten oder zweimal kurz hintereinander, konnte derselbe Job ebenfalls zweimal starten; er startet jetzt einmal.

• Das rclone von vor einem Upgrade lief weiter: Ein von der vorherigen Version zurückgelassenes laufendes rclone wurde nach dem Upgrade von RcloneView weiterverwendet, sodass das neu mitgelieferte rclone erst verwendet wurde, nachdem dieser Prozess von Hand beendet worden war. RcloneView startet rclone jetzt neu, wenn sich die laufende Version unterscheidet. Außerdem hält es kein anderes Programm, das zufällig den Port von rclone verwendet, mehr für rclone – wodurch die App nur Keine Verbindung anzeigte – und startet rclone stattdessen auf dem nächsten freien Port. Beim Beenden oder Neustarten von rclone wartet die App jetzt, bis sich rclone selbst beendet hat; früher wurde es jedes Mal zwangsweise beendet, noch bevor Mounts ausgehängt und der VFS-Cache aufgeräumt wurden.

• Benutzerdefinierte Flags und globale Flags werden tatsächlich angewendet: Die von Ihnen konfigurierten Flags wurden auf mehrere verschiedene Arten stillschweigend verworfen, weshalb ein Flag, das auf der Kommandozeile funktionierte, in der App scheinbar nichts bewirkte. In diesem Release behoben: Globale rclone-Flags aus den Einstellungen wurden nicht auf Sync-/Copy-Jobs angewendet; Backend- und prozessweite Flags in den benutzerdefinierten Flags eines Jobs wurden ignoriert; Felder der Batch-Schritte (Bandbreitenlimit, Einschließen, Mindestalter, Höchstalter, Mindestgröße, Maximalgröße) wurden in einer Form gesendet, die rclone verwirft; ein boolesches Flag, das mit einer Zahl geschrieben wurde (--checksum=1, auf der Kommandozeile gültig), ließ die gesamte Anfrage fehlschlagen, sodass der Job nie startete; wiederholte Flags --backup-dir und --compare-dest wurden abgelehnt; --header, --header-upload, --header-download und --compare-dest wurden in den falschen Typ umgewandelt; der Flag-Parser kam mit Anführungszeichen oder Leerzeichen innerhalb eines Wertes nicht zurecht; ein Probelauf enthielt die benutzerdefinierten Flags überhaupt nicht, sodass die Vorschau nicht zum echten Lauf passte; und ein einziges fehlerhaftes Zeichen im Feld für globale Flags verwarf stillschweigend jedes Flag statt nur des betreffenden.

• Eine fehlgeschlagene Synchronisation meldet nicht mehr „Keine Änderungen“: Eine Synchronisation, die fehlschlug, bevor etwas übertragen wurde – falsche Zugangsdaten, ein nicht erreichbares Remote, ein fehlender Pfad –, wurde in der Jobliste, im Verlauf und in Benachrichtigungen als abgeschlossener Lauf ohne Änderungen angezeigt. Die von rclone für den Job gemeldeten Fehler werden jetzt gelesen, sodass ein Fehlschlag als Fehlschlag angezeigt wird.

• Eine fehlgeschlagene Auflistung wird nicht mehr als leerer Ordner behandelt: Wenn ein Ordner nicht aufgelistet werden konnte, nahmen mehrere Teile der App an, er sei einfach leer. So konnte ein Mount auf vorhandene Inhalte gelegt werden, so bestand die Überprüfung Überprüfen eines Mounts immer, und so konnten die Ordnerstruktur, der Vergleich und die Pfadauswahl für einen Ordner voller Dateien gar nichts anzeigen. Eine fehlgeschlagene Auflistung wird jetzt als Fehlschlag gemeldet – auch die Listenansicht zeigt sie an, statt wie ein leerer Ordner auszusehen.

• Abgebrochene Anmeldungen blockierten alle neuen Remotes: Wenn die Anmeldeseite eines Anbieters geschlossen wurde, ohne sie abzuschließen, hielt der Autorisierungshelfer von rclone den Port 53682 weiter belegt, und jeder spätere Versuch, ein Remote zu erstellen, das sich über einen Browser anmeldet, schlug fehl. Ein Neustart der App gab ihn nicht frei – das zwangsweise Beenden von rclone war der einzige Ausweg. Der Helfer wird jetzt beendet, wenn eine Anmeldung abgebrochen wird.

Neue Funktionen und Verbesserungen

• Upload-Parallelität pro Job: Die Backend-Upload-Parallelität (upload_concurrency) lässt sich jetzt für einen einzelnen Job festlegen statt nur global, sodass ein Job gegen ein schnelles Remote sich keine Einstellung mit allem anderen teilen muss.

• Neue Remotes öffnen sich direkt in einem Bereich: Nachdem Sie ein Remote erstellt haben, wird es jetzt sofort in einem Explorer-Bereich geöffnet, statt Sie es selbst suchen und öffnen zu lassen.

• Freier Speicherplatz im Explorer: Bei Remotes, die ihn melden können, wird der verbleibende Speicherplatz des Remotes jetzt im Datei-Explorer angezeigt.

• Schnelleres Kopieren aus der Vergleichsansicht: Beim Kopieren aus der Vergleichsansicht wurde pro Element ein rclone-Job gestartet, und es liefen vier gleichzeitig, unabhängig davon, was für --transfers eingestellt war. Elemente werden jetzt pro Remote und übergeordnetem Ordner zu einem Sync/Copy zusammengefasst, und Ihre Einstellung für --transfers wird beachtet.

• Das Popup „Konfigurationsdatei geändert“ unterbricht nicht mehr: Der Hinweis, dass sich die rclone-Konfigurationsdatei auf der Festplatte geändert hat, übernimmt nicht mehr mitten in dem, was Sie gerade tun, den Bildschirm.

• Lizenzregistrierung hinter strengen Proxys: Manche Universitäts- und Firmenproxys blockieren die Anfragemethode, mit der eine Lizenz registriert wird. Registrierung und Aufhebung der Registrierung weichen jetzt auf eine zweite Methode aus, wenn die erste abgelehnt wird.

• Der Rückfall bei globalen Flags ist enger gefasst: Wenn ein globales Flag nicht angewendet werden konnte, verwarf die App früher die gesamte Menge – und nahm funktionierende Flags wie --bwlimit mit. Jetzt wird nur noch das Flag verworfen, das das Problem verursacht hat.

• Hinweise zu Google Photos: Google Photos listet nur Fotos auf, die von dieser App hochgeladen wurden; das ist eine von Google auferlegte Einschränkung – dies wird jetzt in der App erklärt, statt wie ein leeres Konto auszusehen. Wenn keine Verbindung hergestellt werden kann, führt die App Sie außerdem durch das Erstellen Ihrer eigenen OAuth-Client-ID.

• Verständlichere Warnungen zu benutzerdefinierten Flags: Der Warntext für timeout, contimeout und user-agent in den benutzerdefinierten Flags wurde korrigiert.

• Auswahl eines Mount-Punkts: Der Assistent prüft einen Mount-Punkt, sobald Sie ihn eingeben oder dorthin navigieren, zeigt den Grund an, wenn er nicht verwendet werden kann, und lässt Weiter deaktiviert – statt im letzten Schritt zu scheitern und im Einbindungs-Manager einen fehlgeschlagenen Eintrag zu hinterlassen. Er schlägt nur Orte vor, die tatsächlich angelegt werden können, beginnend mit ~/Mounts/<remote>; bei einer Verbindung zu rclone auf einem anderen Rechner schlägt er einen Ordner unter dem Home-Verzeichnis dieses Rechners vor. Durchsuchen fügt in dem gewählten Ordner einen nach dem Remote benannten Ordner hinzu, und Neuen Ordner darin verwenden behebt einen Ordner, der so nicht verwendet werden kann – unter Windows darf der Mount-Ordner noch nicht existieren, unter macOS und Linux muss er leer sein. Der Einbindungs-Manager prüft vor dem Speichern dieselben Regeln, unter Windows einschließlich eines übergeordneten Ordners, in dem Ihr Konto keine Ordner anlegen kann, und zeigt, warum ein Mount fehlgeschlagen ist, statt nur Einbindung fehlgeschlagen.

• Interaktive Demos aus dem Assistenten: Jede Aufgabe auf dem Willkommensbildschirm des Assistenten hat einen Link Demo, der in Ihrem Browser eine interaktive Anleitung für diese Aufgabe öffnet, und Alle Demos listet sie alle auf.

• iCloud Photos: Die Gesamtzahl der Fotos wird jetzt während der ersten Synchronisation angezeigt, sodass ein langer erster Lauf nicht mehr wie festgefahren aussieht, und ein Doppelklick auf eine Miniatur kann sie in der Vorschau öffnen.

Fehlerbehebungen

Jobs, Batches und Übertragungen

• Das Umbenennen eines Ordners auf S3 ließ den alten Ordner zurück: Die Schritte „Umbenennen“ und „Verschieben“ in einem Batch verschoben den Inhalt, ließen aber den ursprünglichen Ordnermarker bestehen, sodass der alte Ordner weiter im Explorer erschien. Bei Objektspeicher ist ein Ordner ein Marker-Objekt, und der Batch-Schritt legte am Ziel nie eines an und entfernte auch das an der Quelle nicht. Das Umbenennen im Auftrags-Manager hatte dieselbe Lücke und führte zusätzlich die Bereinigung des alten Ordners gleichzeitig mit dem Verschieben aus, sodass die beiden miteinander konkurrierten; bei einem leeren Ordner wurde am Ende gar kein neuer Ordner angelegt. Beide legen jetzt den Zielmarker an und entfernen den Quellmarker, und zwar in dieser Reihenfolge.

• Erneutes Versuchen einer Umbenennung auf S3 und Swift: Das erneute Versuchen einer Ordnerumbenennung hinterließ einen leeren Marker für den ursprünglichen Ordner.

• Erneut versuchen konnte einen anderen Job ausführen: Nachdem rclone neu gestartet worden war, konnten sich eine wiederhergestellte Zeile und ein aktueller Job dieselbe Job-ID teilen, sodass Erneut versuchen den falschen Job erneut ausführte.

• Erneut versuchen schlug bei Batch-Übertragungen mit mehreren Elementen immer fehl: Die Schaltfläche „Erneut versuchen“ bei einer Batch-Übertragung mit mehreren Elementen war nie erfolgreich.

• Anzahl der Multi-Thread-Übertragungen wurde bei S3 ignoriert: Der Wert Anzahl der Multi-Thread-Übertragungen hatte bei S3-Zielen keine Wirkung, dort setzte sich stattdessen die eigene Upload-Parallelität des Backends durch.

• Doppelte Jobnamen durch den Assistenten: Der Assistent bildete den Namen eines Jobs allein aus dem Pfad, sodass zwei Jobs denselben Namen erhalten konnten – und das wiederum blockierte das Speichern, wenn Sie einen von beiden bearbeiteten.

• Der Probelauf zeigte mit anderen Optionen als der Lauf: Ein Probelauf eines Jobs, eines Batches oder des Assistenten ignorierte Globale rclone-Flags und prüfte immer mit --transfers=4 --checkers=8, sodass eine niedrigere Checker-Anzahl, die zur Schonung eines ausgelasteten Servers eingestellt wurde, für die Vorschau nicht galt. In der Vorschau eines Batch-Kopierschritts fehlten die Optionen des Schritts, benutzerdefinierte Flags außer Filtern (wie --fast-list und --compare-dest) fehlten in jeder Vorschau, und --checksum wurde anders übergeben als beim echten Lauf.

• Crypt-Uploads blieben bei über 100 % auf „Läuft“: rclone zählt einen Crypt-Upload in verschlüsselten Bytes, die etwas mehr sind als die Größe der Datei. Dateizeilen eines abgeschlossenen Crypt-Uploads blieben in der Übertragungsliste und im Verlauf auf Läuft und zeigten während des Laufs Werte wie 183 %.

• Eine Sync-Benachrichtigung öffnete die Details eines anderen Laufs: rclone nummeriert seine Jobs bei jedem Start wieder ab 1, sodass ein Klick auf eine Abschlussbenachrichtigung Quelle, Ziel und Fehler eines anderen Laufs anzeigen konnte, der dieselbe Nummer wiederverwendet hatte.

• Gelöschte geplante Batches liefen weiter: Ein im Auftrags-Manager gelöschter geplanter Batch lief weiter nach Zeitplan, bis die App neu gestartet wurde. Außerdem behoben: Ein Job mit beschädigten Einstellungen hinderte den Verbindungsmanager daran, Verbindungen zu wechseln; Zeitplanänderungen, die beim Neuladen der Zeitpläne vorgenommen wurden, gingen verloren; und zweimaliges schnelles Klicken auf Löschen konnte den Auftrags-Manager schließen.

Mounts

• Mounten über eine Remote-rclone-Verbindung: Bei einer Verbindung zu rclone auf einem anderen Rechner prüfte die App den Mount-Punkt weiterhin auf dem lokalen Rechner und legte ihn dort an, sodass das Mounten von einem Mac oder Linux-PC aus immer fehlschlug.

• Langsame Laufwerke wurden als „Übergeordneter Ordner existiert nicht“ gemeldet (Windows): Das Anlegen des übergeordneten Ordners war an dasselbe Zeitlimit gebunden, das zum Prüfen des Laufwerks verwendet wird, sodass ein langsames Laufwerk fälschlich als fehlend diagnostiziert wurde.

• Gespeicherte Mounts verschwanden, wenn sich der rclone-Port änderte: Von Ihnen gespeicherte Mounts verschwanden aus der Liste, nachdem das eingebettete rclone auf einem anderen Port gestartet worden war.

• „Too many open files“ nach einer Weile: Antworten von rclone wurden auf manchen Wegen nicht vollständig gelesen, wodurch jedes Mal ein Dateideskriptor verloren ging, bis das Mounten überhaupt nicht mehr funktionierte.

• SFTP band das Home-Verzeichnis statt des Server-Roots ein: Die Pfadnormalisierung entfernte den führenden Schrägstrich des Mount-Ziels, sodass ein Mount des Server-Roots im Home-Verzeichnis des Kontos landete.

• Lokale Laufwerksnamen in der Mount-Liste: Die Anzeige lokaler Laufwerksnamen wurde korrigiert.

• Eingebundene Remotes als „konfiguriert“ aufgelistet: Unter Windows und bei einer Verbindung zu rclone auf einem anderen Rechner wurde ein eingebundenes Alias-Remote, ein benanntes lokales Remote oder ein Alias, der auf einen Laufwerksbuchstaben zeigt, als konfiguriert mit einer Schaltfläche Einbinden aufgelistet, sodass es sich nicht über seine Zeile aushängen ließ.

• Erfolgreiche Aushängevorgänge wurden als Fehler verzeichnet: Zweimaliges Aushängen, das Aushängen von etwas, das anderswo bereits ausgehängt wurde, oder ein Aushängen, das länger als 30 Sekunden dauerte – ein NFS-Mount unter macOS wartet, bis der Finder das Volume freigibt –, ließ die Zeile auf Fehler hängen. RcloneView prüft jetzt, ob der Mount tatsächlich verschwunden ist.

• Der Einbindungs-Manager ließ den Laufwerksbuchstaben weg (Windows): Im Modus Einbindung auf lokalen Pfad wurde ein mit Durchsuchen gewählter Ordner ohne seinen Laufwerksbuchstaben gespeichert, sodass Speichern und einbinden fehlschlug und der fehlgeschlagene Eintrag in der Liste blieb.

• Ein Fehlerfenster vor der Ordnerauswahl (Windows): Wenn Sie auf Lokalen Ordner durchsuchen klickten, während der Mount-Punkt noch Auto: war, erschien vor der Ordnerauswahl „You can't open this location using this program“.

• Laufwerksbuchstaben-Mounts fehlten im Tab für lokale Datenträger (Windows): Ein über den Assistenten eingebundener Laufwerksbuchstabe erschien im Datei-Explorer, aber nicht im Tab für lokale Datenträger von RcloneView, weil der Tab aktualisiert wurde, bevor der Laufwerksbuchstabe erschien. Der Tab wartet jetzt darauf.

Explorer, Vergleich und Filter

• Backslashes in Objektnamen (Windows): Ein Cloud-Objekt, dessen Name einen Backslash enthält, wurde auf Windows-Hosts so zerlegt, als wäre er ein Ordnertrennzeichen.

• Backslashes in Dateinamen (macOS und Linux): Die Pfadnormalisierung führte dazu, dass Dateien mit einem Backslash im Namen nicht mehr zu den Ausschlussregeln passten.

• Maskierte Mustersonderzeichen in Filtern: Die eigene Filtervorschau der App konnte maskierte Mustersonderzeichen nicht abgleichen, sodass das, was Sie auf dem Bildschirm sahen, und das, was rclone tatsächlich tat, voneinander abwichen.

• Versteckte Dropbox-Dateien wurden trotzdem kopiert: Der Ausschluss für versteckte Dateien von Dropbox galt beim Kopieren eines Verzeichnisses nicht.

• Lokale Laufwerke fehlten im Browser (Windows): Lokale Laufwerke erschienen nicht im Browser.

• Fehler nach der Verwendung des Vergleichs: Die häufigen Fehler beim Ausführen eines Vorgangs nach einem Vergleich wurden behoben.

• Öffnen verwendete immer den linken Bereich: Öffnen im Remote-Manager legte das Remote unabhängig davon, in welchem Bereich Sie arbeiteten, im linken Bereich ab und ersetzte dabei die Ansicht, mit der Sie verglichen. Es öffnet sich jetzt im aktiven Bereich.

• Explorer-Tabs wurden beim Neustart von rclone geschlossen: Wenn das eingebettete rclone auf einem anderen Port zurückkam – nach Rclone neu starten oder beim Verbinden über den Verbindungsmanager – oder Rclone aktualisieren seine Version änderte, wurde jeder Remote-Tab in beiden Bereichen geschlossen, und die Tabs kamen nach einem Neustart der App nicht zurück.

Start, App-Sperre, Beenden und Lizenzierung

• Das Dock-Symbol umging die App-Sperre (macOS): Ein Klick auf das Dock-Symbol, während die App gesperrt war, öffnete das Fenster, ohne nach dem Passwort zu fragen.

• Das Tray-Menü umging die App-Sperre: Solange die App gesperrt und im Tray verborgen war, wurden die Einträge Einbinden des Trays – das Einbinden oder Aushängen eines gespeicherten Mounts und Alle aushängen – ohne das Passwort ausgeführt, und ein Mount, der so eingestellt war, dass er sich im Dateimanager öffnet, öffnete auch seinen Ordner. Wenn das Fenster minimiert statt verborgen war, fügte Öffnen → Remote den Tab hinzu, bevor nach dem Passwort gefragt wurde. All dies fragt jetzt zuerst nach.

• Zwei Passwortabfragen über den Tray (Windows): Die Auswahl eines Tray-Untermenüeintrags wie Öffnen → Remote oder Einbinden → Neue Einbindung bei minimiertem gesperrtem Fenster öffnete zwei Passwortabfragen; nach dem Entsperren blieb die zweite über der App liegen, und ein Klick auf Beenden darin beendete RcloneView.

• Passwortabfrage für den Schlüsselbund beim Start (Linux): Wo der Login-Schlüsselbund gesperrt bleibt – automatische Anmeldung, Remote-Desktop, Anmeldung per Fingerabdruck –, fragte RcloneView bei jedem Start nach einem Passwort, bevor sein Fenster erschien. Es war der GNOME-Schlüsselbund, der um Entsperrung bat, keine Anfrage nach Administratorrechten, und das Abbrechen ließ die App einfrieren. RcloneView greift unter Linux nicht mehr auf den Schlüsselbund zu.

• Der Assistent öffnete sich über dem Sperrbildschirm: Der Assistent konnte über dem Bildschirm App-Sperrpasswort eingeben erscheinen.

• App zurücksetzen aus einem sekundären Fenster: Wenn App zurücksetzen auf dem Sperrbildschirm eines sekundären Fensters ausgeführt wurde, lief das Hauptfenster mit Einstellungen und einer Datenbank weiter, die bereits gelöscht worden waren.

• „Rclone beim Beenden der App stoppen“ wurde ignoriert: Das Beenden mit ⌘Q oder durch Schließen des Fensters unter macOS sowie Beenden oder App zurücksetzen auf dem Sperrbildschirm ignorierten die Einstellung Rclone beim Beenden der App stoppen.

• Der Neustart von rclone konnte ewig hängen: Der Neustart von rclone nach einer Konfigurationsänderung konnte an einer endlosen Ladeanzeige hängen bleiben, weil die Anfrage zum Beenden des alten Prozesses kein Zeitlimit hatte.

• Der Ablauf der Testversion wurde nur beim Start geprüft: Ob die Testversion abgelaufen war, wurde einmal beim Start des Prozesses entschieden und nie neu bewertet.

• Automatischer Mount nach dem Upgrade auf eine kostenpflichtige Lizenz: Der automatische Mount lief nach dem Wechsel zu einer kostenpflichtigen Lizenz nicht, weil die Prüfung lief, bevor die Lizenzprüfung abgeschlossen war.

• Fehlermeldungen bei der Lizenzregistrierung: Wenn die Registrierung fehlschlägt, wird die Ursache jetzt in Ihrer Sprache angezeigt. Ein Server, der nicht antwortet, wird als nicht erreichbar gemeldet, mit dem Hinweis, Internetverbindung, Firewall und Proxy zu prüfen, statt als unerwarteter Fehler. Proxy-Hinweise erscheinen nicht mehr bei Fehlern wie einem ungültigen Schlüssel, und die kopierte Diagnose nennt die Anfragemethode, die tatsächlich blockiert wurde.

Remotes erstellen und anmelden

• Fehlende anbieterspezifische Optionen: Optionen, die zu einem bestimmten Anbieter gehören, wurden nach dem falschen Namen gefiltert, sodass die Zugangsdaten für Storj, der Koofr-Endpunkt und mehrere Oracle-Felder nie erschienen.

• Erforderliche Optionen unter „Erweitert“ versteckt: Compress ließ sich nicht speichern, weil die erforderliche Option level unter den erweiterten Optionen versteckt war, und Oracle Object Storage wurde auf dieselbe Weise durch compartment blockiert.

• Authentifizierungsmethoden bei Oracle: Die Auswahl von no_auth oder user_principal_auth aus der Liste konfigurierte den Anbieter falsch.

• Das Speichern eines bearbeiteten Remotes konnte hängen: Das Speichern einer Änderung an einem bestehenden Remote konnte in rclone nicht mehr reagieren.

• OneDrive Personal: Das Einrichten eines persönlichen Remotes konnte bei Verbindung überprüfen hängen bleiben, wobei der zugrunde liegende Fehler verborgen blieb, und eine fehlgeschlagene Laufwerksabfrage konnte ein leeres Remote speichern.

• iCloud-Konten, die auf die Nutzungsbedingungen warten: Ein Konto, das die aktualisierten Nutzungsbedingungen von Apple nicht akzeptiert hatte, schlug nur mit no auth method found fehl, ohne dass sich erkennen ließ, was nicht stimmte. Der tatsächliche Grund wird jetzt angezeigt.

• Client-ID bei Google Photos: Die Anforderung, eine eigene Client-ID zu verwenden, wurde auf dem Weg, den die App tatsächlich nimmt, nicht angewendet.

Assistent

• Bearbeiten eines vom Assistenten erstellten Jobs: Quelle und Ziel sahen beim Bearbeiten leer aus, und das Speichern überschrieb die echten Werte mit diesen leeren.

• Mount-Ort bei einem Remote-rclone (Windows): Der Assistent schlug als Mount-Ort einen Home-Pfad auf dem lokalen Rechner vor, während eine Verbindung zu rclone auf einem anderen Rechner bestand.

• Lokaler Ordner als Backup-Quelle (Windows): Die Wahl eines lokalen Ordners als Quelle löste einen Fehler aus.

• Mounten über den Assistenten (Windows): Das Mounten über den Assistenten schlug weit häufiger fehl, als es sollte.

• Erneuter Versuch mit demselben Remote-Namen: Nach einer fehlgeschlagenen Anmeldung wurde es abgelehnt, auf Zurück zu gehen und es mit demselben Remote-Namen erneut zu versuchen.

• Umbenennen des Remotes mit „Zurück“: Wenn Sie nach dem Erstellen eines Remotes auf Zurück gingen und unter einem neuen Namen fortfuhren, blieb das alte Remote neben dem neuen aufgelistet, bis der Assistent geschlossen wurde. Wenn die Aufgabe bereits gelaufen war, löschte das Umbenennen das Remote, auf das der gespeicherte Mount, der geplante Job oder das Crypt-Remote zeigte. Das frühere Remote wird jetzt sofort entfernt, und nur dann, wenn nichts vom Assistenten Gespeichertes es verwendet.

• iCloud Photos im Assistenten: Das Hinzufügen eines iCloud-Photos-Remotes nach der Verwendung von Durchsuchen löste einen Fehler aus. iCloud Photos wird jetzt nur noch in der Aufgabe Durchsuchen angeboten; die Aufgaben Backup, Synchronisieren, Mount, Vergleichen und Crypt listen es nicht mehr auf. Jobs, die iCloud Photos bereits als Quelle verwenden, laufen weiter, und Sie können weiterhin im Auftrags-Manager einen anlegen.

Sprache und Oberfläche

• Nicht übersetzte Bildschirme: Das Sprachauswahlmenü selbst, die beiden Feldbezeichnungen der Telegram-Fernsteuerung, der Einstellungsbereich Webserver und die iCloud-Photos-Einstellung „sync automatically when the tab is activated“ wurden in jeder Sprache auf Englisch angezeigt. In der japanischen Bestätigung zum Löschen eines Jobs fehlte der Name des Jobs.

• Schalterzeilen in den Einstellungen: Schalterzeilen in einem umrandeten Einstellungsbereich zeigten keinen Tinteneffekt und lösten eine Debug-Assertion aus.

• Hilfe-Popup im Terminal: Die Eingabe eines Verzeichnisnamens im Terminal wurde als Befehl behandelt und brachte das Hilfe-Popup hervor.

• Versionsinformationen (Windows): Die für RcloneView angezeigten Versionsinformationen wurden korrigiert.

• Das Ändern des Datenbankordners brach das Speichern: Nachdem der Datenbankordner in den Einstellungen geändert worden war, schlug jedes Speichern und Abfragen von Jobs, Mounts und Verlauf fehl, bis die App neu gestartet wurde.

Paketierung und Updates

• Mitgeliefertes rclone unter Linux: Die Linux-Pakete wurden mit dem rclone gebaut, das gerade auf dem Build-Rechner vorhanden war, und konnten eine Entwicklungsversion von rclone 1.60.1 enthalten. Die Linux-Builds liefern jetzt dasselbe festgelegte rclone mit wie die anderen Plattformen.

• Updates erreichten bestehende deb/rpm-Installationen nicht: Ein gespeicherter rclone-Pfad hatte Vorrang vor der mitgelieferten Binärdatei, sodass das mitgelieferte rclone nach einem Update nie wirksam wurde.

• „Rclone aktualisieren“ meldete Erfolg, obwohl es immer fehlschlug (Linux): Das direkte Aktualisieren des mitgelieferten rclone konnte unter einem normalen Benutzerkonto nicht gelingen, aber die App meldete trotzdem Erfolg, weil sie das Ergebnis am Exit-Code des Terminals beurteilte – und der Versuch unterbrach laufende Übertragungen.

• „Rclone aktualisieren“ lehnte ein rclone ab, das Ihnen gehört (Linux): Wenn Lokaler rclone-Speicherort auf ein rclone zeigte, das Ihrem Konto gehört, zeigte Rclone aktualisieren denselben Hinweis „Schreiben nicht möglich“ wie beim mitgelieferten und versuchte es nie, sodass rclone unter Linux überhaupt nicht über die App aktualisiert werden konnte. Ein rclone, das Ihnen gehört, wird jetzt aktualisiert; das mitgelieferte bleibt weiterhin dem Paket überlassen.

• Das aarch64-RPM ließ sich nicht installieren: Das aarch64-rpm führte eine nur für Rockchip gedachte Bibliothek (librockchip_mpp) als Abhängigkeit auf, sodass dnf install es unter Fedora und anderen Distributionen, die sie nicht bereitstellen, verweigern konnte.

• Stille Build-Fehler: Ein Build, bei dem der Installer-Schritt fehlgeschlagen war, konnte trotzdem veröffentlicht werden, als wäre er erfolgreich gewesen, sowohl unter Windows als auch unter macOS. Diese Skripte schlagen jetzt deutlich fehl.