Wasted disk space / verschwendeter Platz auf der Festplatte

For an English version of my question scroll down please.

Hallo!

Ich verwende Cryptomator zusammen mit OneDrive nun schon seit etwas mehr als einem Jahr. Ich verwende Ondedrive um Dateien von fünf Rechnern miteinander zu synchronisieren. Das sind:
2 x Windows 10
2 x MacOS (Catalina)
1 x Linux (Ubuntu 19.04 Disco Dingo)
Auf jedem dieser fünf Rechner läuft Cryptomator in der jeweils aktuellsten Version, und abgesehen von Conflict-Dateien, die manchmal aus Gründen entstehen die ich nicht immer nachvollziehen kann, funktioniert das alles auch recht gut.
Aber ich habe heute mal den Speicherplatz des Inhalts des Tresors mit dem Speicherplatz verglichen, den der OneDrive-Ordner auf meinem Rechner belegt (die Werte sind auf allen 5 Rechnern gleich):

Der ständig vorhandene ordner “encrypted” im Verzeichnis “OneDrive”, der von OneDrive mit der Cloud synchronisiert wird, ist 1,59 GB groß (1.591.146.413 Byte) und enthält 2.736 Objekte.
Der Inhalt des virtuellen Laufwerks “encrypted” ist aber nur 684,1 MB groß (684.064.615 Byte) und enthält nur 569 Objekte.

Jeweils 100 Byte im Tresor stehen 233 Byte in der Cloud gegenüber.

  1. Warum ist das so?
  2. Was kann man dagegen tun?

English:

Hi!

I’ve been using Cryptomator with OneDrive for about one year now. I use Ondedrive to synchronize files from five computers. These are:
2 x Windows 10
2 x MacOS (Catalina)
1 x Linux (Ubuntu 19.04 Disco Dingo)
On each of these five computers runs the latest version of Cryptomator, and apart from “conflict” files, which sometimes arise for reasons that I cannot always understand, it all works quite well.
But today I compared the storage space of the contents of the vault with the storage space that the OneDrive folder uses on my computer (the values are the same on all 5 computers):

The constantly existing “encrypted” folder in the “OneDrive” directory, which OneDrive synchronizes with the cloud, is 1.59 GB large (1,591,146,413 bytes) and contains 2,736 objects.
The content of the “encrypted” virtual drive has a size of only 684.1 MB (684,064,615 bytes) and contains only 569 objects.

Each 100 bytes in the vault contrast with 233 bytes in the cloud.

  1. Why is that?
  2. What can you do about it?

Hallo und willkommen.
Ich nutze ebenfalls OneDrive (nur auf Windows) und kann das Verhalten bei mir nicht feststellen. Mein lokal benötigter Platz entspricht genau dem belegten Speicherplatz in Onedrive.
Ich nehme an Du hast schon überprüft dass nicht einer der Sync Client zusätzliche Dateiversionen anlegt wenn Änderungen an den Dateien gemacht werden.
Du könntest auch die Dateien aus OneDrive in ein separates Verzeichnis herunterladen und mit einem Dateivergleichs-Tool prüfen ob und wenn ja welche Dateien zwar online aber nicht lokal liegen.
Vielleicht ergeben sich hieraus Erkenntnisse um die Ursache Deines Problems einzugrenzen.


Hello and welcome.
I also use OneDrive (only windows) and I can’t detect the behavior on my end. My locally required space is exactly the same as the space used in Onedrive.
I assume you have already checked that not one of the sync clients creates additional file versions when changes are made to the files.
You could also download the files from OneDrive into a separate directory and use a file comparison tool to check if and which files are online but not local.
Maybe this helps to find out the cause of your problem.

Hallo Michael!

Das mit den Dateiversionen verstehe ich nicht ganz. Wenn es von einer Datei mehrere Versionen gibt, gibt es diese Versionen ja sowohl im Tresor, als auch in der verschlüsselten Version des Tresors. Bis auf den notwendigen kleinen Overhead für die Verschlüsselung selbst müssten auch dann 100 Byte im Tresor höchstens 105 Byte in der verschlüsselten Version, die über die Cloud synchronisiert wird, entsprechen.

Ich lade gerade die Dateien von der Online-Website von OneDrive herunter. Das Verzeichnis d dauert noch, aber das Verzeichnis m ist absolut identisch mit der Version, die lokal auf jedem meiner 5 Rechner liegt.
Vom Verzeichnis d kann ich aber schon sagen, dass es in der Cloud und lokal exakt dieselben 481 Unterverzeichnisse enthält.

Derzeit sieht es so aus, also würde das, was in der Cloud liegt absolut identisch sein mit der synchronisierten lokalen Kopie.

Es deutet also nach wie vor alles darauf hin, dass OneDrive völlig korrekt arbeitet, und dass Cryptomator vergisst bei den verschlüsselten Dateien Inhalte zu löschen, die im Tresor schon seit Monaten nicht mehr existieren.


Hi Michael!

I don’t quite understand the file versions. If there are several versions of a file, these versions exist both in the vault and in the encrypted version of the vault. Except for the small overhead required for encryption itself, 100 bytes in the vault would have to be a maximum of 105 bytes in the encrypted version, which is synchronized via the cloud.

I am currently downloading the files from the OneDrive online website. The directory d is still running, but the directory m is absolutely identical to the version that is local to each of my 5 computers.
However, I can already say that directory d contains exactly the same 481 subdirectories in the cloud and locally.

It currently looks as if the cloud would be absolutely identical to the synchronized local copy.

So everything still suggests that OneDrive works completely correctly, and that Cryptomator forgets to delete the encrypted files that have not existed in the vault for months.

Hi.
Ich meinte die verschlüsselten Tresor Dateien in OneDrive, nicht die Dateien im Tresor.
Wenn du Datei a im Tresor updated, wird die verschlüsselte Datei ja ebenfalls geändert. Wird diese Änderung nun mit OneDrive synchronisiert, und hat OneDrive eine versionierung aktiv, dann wird online die „alte“ Tresor Datei nicht gelöscht sondern als 2. Version aufbewahrt. So zumindest meine Idee.

Danke, das war ein interessanter Hinweis.

Ich habe in den Einstellungen der OneDrive-App (zumindest am Mac) keinerlei Hinweise auf Versionen gefunden. Ich nahm nämlich an, wenn es von einzelnen oder sogar von allen Dateien neben der aktuellen zusätzlich auch noch ältere Versionen gäbe, dann müsste es auch einen Weg geben, via App an die alten Versionen ranzukommen. Das ist definitiv nicht der Fall. Daher nahm ich an, es gäbe in OneDrive keine Versionierung.

Allerdings fand ich auf der Website von OneDrive gleich mal einen Papierkorb (den die App vollkommen verschweigt). Den habe ich gleich mal entleert, dadurch wurden laut Meldung ca. 450 MB gelöscht.

Und dann habe ich gesehen, dass man für jede einzelne Datei nachsehen kann, welche alten Versionen es gibt. Ich habe das bei 6 Dateien gemacht, von allen gab es jeweils nur die aktuelle Version.

Woanders habe ich gelesen, dass OneDrive nur Office-Dateien versioniert. Nachdem OneDrive aber nur verschlüsselte Dateien sieht, die entweder gar keine Dateiendung oder die Endung .Ing haben, gehe ich mal davon aus, dass OneDrive ohnehin keine alten Versionen meiner Dateien speichert, sondern immer nur die neuen.

Kann man OneDrive irgendwie dazu überreden, weder den Papierkorb zu benutzen, noch alte Dateiversionen zu speichern? Ich will, dass in der Cloud ausschließlich die aktuellen Versionen von meinen Dateien existieren, und dass beim Löschen einer Datei diese Datei wirklich endgültig aus der Cloud entfernt wird.

Ich habe übrigens vor dem Leeren des Online-Papierkorbes 5 Dateien aus dem Tresor gelöscht.
Der Inhalt des Tresors ist jetzt 444,7 MB groß (444.694.591 Byte) und besteht aus 564 Objekten. Von OneDrive synchronisiert werden aber 1,35 GB (1.352.751.102 Byte) bzw. 2.732 Objekte. Das Speicherplatzverhältnis beträgt nun aber sogar 100 : 304.


Thanks, that was an interesting hint.

I did not find any references to versions in the settings of the OneDrive app (at least not in the MacOS version). I assumed that if there were also older versions of individual or even all files in addition to the current version, there should also be a way to get to the old versions via the app. That is definitely not the case. So I assumed there was no versioning in OneDrive.

However, I found a recycle bin on the OneDrive website (which the app does not mention). I emptied it right away, and according to the message about 450 MB were deleted.

And then I saw that you can check which old versions there are for each individual file. I did this for 6 files, there was only the current version of all of them.

I read somethere else that OneDrive only versioned Office files. Since OneDrive only sees encrypted files that either have no file extension or the extension .Ing, I assume that OneDrive doesn’t save old versions of my files anyway, but only the new ones.

Can you somehow persuade OneDrive not to use the recycle bin and not to save old versions of files? I want that only the current versions of my files exist in the cloud and that when a file is deleted, that file is really permanently removed from the cloud.

Incidentally, I deleted 5 files from the vault before emptying the online recycle bin.
The content of the vault is now 444.7 MB (444,694,591 bytes) and consists of 564 objects. However, OneDrive synchronizes 1.35 GB (1,352,751,102 bytes) or 2,732 objects. The storage space ratio is now even 100 : 304.

Hier (zdnet) und hier (office support) lese ich das anders. Demnach wird für jeden Dateityp die Versionierung angeboten, bei private Accounts bis zu 25 Versionen.

Bei OneDrive for Business ist das laut diesem Artikel nicht möglich. Leider habe ich keine Info speziell für private Accounts gefunden. Ich denke der office Support ist da vermutlich das bessere Forum.
Ich bin mir allerdings mit meiner These zur Versionierung auch nicht mehr so sicher. Wenn es stimmt was in dem Artikel steht, und wenn man die Versionierung bei OneDrive 4 Business (was ich nutze) nicht deaktivieren kann, dann stelle ich mir die Frage weshalb mein Online Tresor exakt so groß ist wie mein lokaler Tresor, obwohl ich regelmäßig Änderungen synchronisiere

Wie gesagt, ich kann das leider nicht reproduzieren, und mir gehen auch die Ideen aus. Wenn der Papierkorb leer ist und die Dateien keine Versionen haben, dann sollte Dein Online Platzbedarf ziemlich genau dem der lokalen Tresorgröße entsprechen.

Was hat denn der Download Deines online Tresors und der Datei-Abgleich ergeben?

Danke für die Antwort. Leider hatte ich diese Woche so viel andere Dinge zu tun, das ich erst jetzt Zeit habe zu antworten.

Ich habe von onedrive.live.com den Ordner “encrypted” heruntergeladen. Außerdem habe ich zum ungefähr selben Zeitpunkt Kopien von den Ordnern auf einem Windows-Rechner und von einem iMac gemacht. Das sind die Ergebnisse:

Ordner “encrypted” auf Windows 10:
1.675.980.739 Byte für 2.788 Objekte

Ordner “encrypted” auf iMac:
1.676.425.387 Byte für 2.788 Objekte

heruntergeladene Version:
1.675.980.739 Byte für 2.385 Objekte

Das heißt:
Die Windows-Version und die heruntergeladene Version sind exakt gleich groß.
Die Mac-Version ist um 445 KB größer, enthält aber ganz genau gleich viele Objekte wie die Windows-Version.

Ein Vergleich von onedrive.live.com mit der von dort heruntergeladenen Version zeigt, dass leere Ordner zwar online (und in den Versionen von Windows und iMac) existieren, aber beim Herunterladen nicht mitgeliefert wurden. Tatsächlich existieren wirklich 403 leere Verzeichnisse, somit ist auch diese Differenz geklärt.

Ein Dateivergleich hat ergeben, dass bis auf die leeren Verzeichnisse die Windows-Version absolut identisch ist mit dem was ich von der Website heruntergeladen habe. Die Mac-Version enthält ein paar neue Dateien, dafür fehlen andere. Den Grund dafür kenne ich leider nicht.

Fakt ist aber, dass der Ordner “encrypted” in allen Versionen rund 1676 MB groß ist, während der Inhalt des Tresors derzeit 780 MB groß ist.

Ich glaube, wir sollten das mal mittels Sanitizer prüfen. Das ist ein kleines Programm, welches sich alle Dateien im d Ordner genau anguckt und prüft ob da ggf. Dinge sind, die dort nicht hingehören.

Wie wohl fühlst du dich im Umgang mit Kommandozeilen-Anwendungen?

Ich betreibe einen Linux-Server und bin dort root. Ich denke, mit Kommandozeilen-Anwendungen komme ich recht gut zurecht. Lieber sind mir aber auf unixoide Rechner (Linux, MacOS). Unter Windows arbeite ich recht selten mit Kommandozeilen-Anwendungen.

Perfekt, dann empfehle ich einmal mittels sanitizer einen “check” durchzuführen. Langfristig wollen wir das aus Cryptomator heraus ermöglichen, aber derzeit brauchst du dazu ein Zusatzprogramm.

Anleitung dazu gibt es hier:

Danke!

Java zu installieren kostete mich schon einige Überwindung. Ich mag keine Software installieren, die ich eigentlich nicht brauche. Und nur wegen des Sanitizers gleiche eine ziemlich mächtige Runtime zu installiren geht mir schon sehr gegen den Strich. (Ich bin von Beruf IT-Sicherheitsforscher und zugegebernmaßen etwas paranoid was das Installieren von Software angeht.) Wenn ich den Sanitizer irgendwie anders anbieten könntet, wäre ich euch sehr dankbar dafür.

Aber ich habs gemacht (Unter Windows 10) und habe den Sanitizer ausgeführt. Das hat er ausgegeben:

# Cryptomator vault sanitizer v0.16 #

Vault password:
Scanning vault structure may take some time. Be patient...
Wrote structure to encrypted.structure.txt.
2860 files in vault

Checking the vault may take some time. Be patient...

Found 84 problem(s):
* 0 FATAL
* 55 ERROR
* 29 WARN
* 360 INFO

See encrypted.check.txt for details.

Done.

Die 55 Errors sehen alle so aus (nur die Dateinamen wechseln). alle 55 gemeldeten Dateien liegen im Verzeichnis m.

ERROR ContentMismatch file: m\2D\TD\2DTDXDU3GO5VTVGL3T22ZJAIZF4CHP5U.lng expected: name with decryptable part actual: 
ERROR ContentMismatch file: m\2G\W6\2GW6KURXCKPN57ZHHBNEPN3AFXKVAFEI.lng expected: name with decryptable part actual:
...

Von den Warnings gibt es 3 verschiedene Arten:

genau 1-mal MissingDirectory path:

WARN  MissingDirectory path: d\P5\CFK2QW4WF2HCMVMJH6YBPSTYIDCLY3 dirfile: d\2P\6ERITQOTSYAIRLI6BWTRTPKP2IYCHA\0NUTJLYMKQORVBSGSUCDIN47MWV5TUNTVTB74CL6NTTFNOF7MEIB7H7UIC7CFSB4HUQ7JVD5KPKMMLQ67JPHO5C3CX6TQXUATHBFQJMVVINA2WENFHDBUT42N notADirectoryButExists: false

27-mal OrphanDirectory (alle im Verzeichnis d):

WARN  OrphanDirectory d\2I\DWHOXV65FTC3Y75NW5XXVYOJA62T7P
WARN  OrphanDirectory d\57\ENZBHGUNGPGWRVO4SL5ESAN45WZOOD
...

1-mal SuspectFile:

WARN  SuspectFile masterkey.cryptomator.20D8D21E.bkup

Und dann folgen 359 gleich aufgebaute Infos (alle: OrphanMFile):

INFO  OrphanMFile m\2C\NA\2CNAMVT2VCPAM2MRJHEBT6VKMAYVF4KV.lng
INFO  OrphanMFile m\2C\WE\2CWEQAKJXWIZFJYO5E3S54ZQFY7O764J.lng
...

Und am Ende 1 Zeile mit einer anderen Info:

INFO  RootExists d\IE\22UNFYB37YKPXBCWLVRBS52ZO2SXIU

Was mache ich nun mit diesen Informationen?

Zweite Frage: Warum sind mehr als die Hälfte aller Verzeichnisse leer? Auszug aus encrypted.structure.txt:

d d\RD
d d\RD\I7HDQQARUFLX3UQFN5WXWWMT5HZQC4
f d\RD\I7HDQQARUFLX3UQFN5WXWWMT5HZQC4\0L7WKIZKIND5MKSVL5EE4WTFE7Y2TJLI7OUC2TJDK 36 B
d d\RE
d d\RH
d d\RJ
d d\RL
d d\RM
d d\RQ
d d\RR
d d\RS
d d\RT
d d\RW
d d\RX
d d\RY
d d\RZ
d d\RZ\OB6PFAAPKR6LLYJ6PWMLLGSQXLSTHP
f d\RZ\OB6PFAAPKR6LLYJ6PWMLLGSQXLSTHP\2FNZKMGQVW6JTE3J3APKUW7724F5B6T36HTEI5TCTXEGOJB2EYIDTMY3OS22RFS5ZLD5S=== ~867 KiB
f d\RZ\OB6PFAAPKR6LLYJ6PWMLLGSQXLSTHP\CLB2KWMD3IWNEL6XVZKDFTNWBN63UDWSEAHBFDPBCARS53ZXU2OT45JCYGDF6XE6WUK3JGIGDY====== ~39 KiB
f d\RZ\OB6PFAAPKR6LLYJ6PWMLLGSQXLSTHP\DMRD4HXDAREEQWNJDOAS4TQRIKYORGDKFUXR5FIT7SLM4CZ3UIOOWTVE7R4HFUVBCZRA==== ~7 KiB
d d\S3
d d\S4
d d\S5
d d\S6
d d\S7
d d\SA
d d\SC
d d\SD
d d\SE
d d\SE\7IXHSC54P56QW72G25BNDCXZNTUSBH
d d\SF
d d\SG
d d\SL
d d\SN
d d\SO
d d\SP
d d\SQ
d d\SQ\HOOL4UXZU2UKWDUWV4BVUUH3A7APER
f d\SQ\HOOL4UXZU2UKWDUWV4BVUUH3A7APER\0V54KTUFDF2CLTWRPMUL7RRQIQBDUQ6YQLWKCFBLFNCSA==== 36 B
d d\SR
d d\SS
d d\SS\AOYZKOPV6ZMKU6MHB4JZRN6HNZCBNF
f d\SS\AOYZKOPV6ZMKU6MHB4JZRN6HNZCBNF\46EELPPMTKVBUDOOSMCIQBHK33IV2C3RYYJXRWYB7APRN6HMEP67G7T5L3TQEWGKWKNFEWRXI4====== ~8 KiB
f d\SS\AOYZKOPV6ZMKU6MHB4JZRN6HNZCBNF\JHMFEOFQR3MEPKSH3HEZKKOEFWXOYJDQ3RX5M2GRXLRW3A4BEEEBNKDTBD2BSIBNLYEWO4A5ZCTQ==== ~2 MiB
d d\ST
d d\SU
d d\SU\A2G32EAJ634NRXJ3CIAGYKQRD2ZOGE
f d\SU\A2G32EAJ634NRXJ3CIAGYKQRD2ZOGE\34UEO44ESIM6QK23V4FJSLCLMOYIPMEZZVTSR7QIME====== ~4 KiB
f d\SU\A2G32EAJ634NRXJ3CIAGYKQRD2ZOGE\C5UC2364RB6JUEQUOMLI5YZGBQFQOCS55SHSTWFAYG3UNISP 493 B
f d\SU\A2G32EAJ634NRXJ3CIAGYKQRD2ZOGE\R2XU43PONL7AVLPNNGKMWADGR5AQHFCDO6MHIPDDTHZZL4NO ~1 KiB

Viel Funktionalität wollen wir direkt in Cryptomator integrieren - falls wir das doch nicht schaffen, wäre der Sanitizer ein heißer Kandidat für AOT-Kompilierung mittels GraalVM.

Die Dateien dürfen nicht leer sein. Der Name der zugehörigen Dateien kann daher nicht entschlüsselt werden. Hier kommt die oben bereits angesprochene Versionierung von OneDrive ins Spiel. (Im Worst Case gibts noch die Option unter Verzicht des Dateinamens den Dateiinhalt zu entschlüsseln…)

Vmtl. einfach nur nicht fertig synchronisiert: Es wird ein Verzeichnis (d\P5\CFK2QW4WF2HCMVMJH6YBPSTYIDCLY3) referenziert, welches nicht gefunden wird.

Das ist der invertierte Fall von MissingDirectory: Existente Verzeichnisse, die nicht referenziert werden. Das würde einen Großteil des Mismatches zwischen Klartext und Ciphertext erklären. Kannste dir vorstellen wie ehemals belegte Bereiche auf ner Festplatte, die im Dateisystem nicht mehr aufgelistet sind.

Kannst du ignorieren, geht auf unsere Kappe. Die Version des Sanitizers kennt diese Dateien einfach noch nicht.

Normalerweise unschädlich, jedoch in Kombination mit den anderen Symptomen ein weiteres Indiz für einen sehr unvollständigen Sync.

Kannste auch ignorieren.

Ordner direkt unterhalb von d/ werden nicht wieder gelöscht, falls einer der n darin befindlichen Ordner gelöscht wird. Da wir uns im Kontext von Sync-Konflikten nicht darauf verlassen können, dass der lokale Stand vollständig ist, gehen wir auf Nummer sicher und lassen diese bestehen. Diese belegen jedoch keinen Speicher und sofern du kein Dateisystem mit einem Knoten-Limit aus den frühen 60er Jahren hast, würde ich empfehlen diese ebenfalls zu ignorieren. Du kannst sie jedoch gefahrlos löschen, wenn du sicher bist, dass alles fertig synchronisiert ist.


Insgesamt hast du sehr viele Warnungen, die darauf hindeuten, dass Dateien und Ordner existieren, die nicht mehr ordentlich “verlinkt” sind, also durch ihre Eltern-Ordner nicht mehr erreichbar sind. Besagte Warnungen sind im Einzelfall meistens synchronisationsbedingte Artefakte konkurrierender Versionen. In der Häufung, in der sie hier auftreten erwecken sie auf mich jedoch den Eindruck, dass (ggf. durch Dritteinwirkung, sei es durch externe Zugriffe oder durch Filterprogramme) ein Großteil der Ordnerstruktur inkonsistent ist.

Alles in allem ein klarer Fall für eine Wiederherstellung. Falls du keine Sicherung hast, kannst du per Sanitizer auch eine vollständige Entschlüsselung besagter nicht-verlinkter Dateien durchführen. Das ist aber als Ultima Ratio zu sehen und kommt wie oben erwähnt zu dem Preis, dass für betroffene Dateien die Namen verloren gehen.

Ich arbeite mit OneDrive und Cryptomator wie folgt:

Ich habe, wie eingangs schon erwähnt, 5 Rechner mit 3 verschiedenen Betriebssystemen (2-mal Win10, 2-mal MacOS Catalina, 1-mal Ubuntu 19.04), die alle dasselbe OneDrive-Konto verwenden um Daten zu synchronisieren.
Auf allen 5 Rechnern verwende ich auch Cryptomator und synchronisiere mit der Cloud die von Cryptomator verschlüsselten Dateien, also das Verzeichnis »encrypted«.

Als ich mal (schon länger her) eine DOCX-Datei mit MS-Word (auf dem iMac) geöffnet habe, stellte ich ein Problem fest: Word legt ja, wenn es eine Datei öffnet, eine zweite versteckte Datei an, die gelöscht wird, wenn man die eigentliche Word-Datei wieder schließt. Diese versteckte Datei (die natürlich ebenfalls im Cryptomator-Tresor lag) verursachte aber einen Synchronisierungskonflikt. Innerhalb weniger Stunden, in denen ich diese Word-Datei offen hatte, wurden über 100 Conflict-Dateien von dieser versteckten Datei erzeugt, die dann natürlich alle bestehen blieben als ich die eigentliche Word-Datei wieder geschlossen habe. Da mir das immer wieder mit Word-Dateien passiert ist die ich von Kollegen bekommen habe, habe ich mir folgende Lösung überlegt:

Ich habe auf jedem der 5 Rechner eine Kopie des Inhalts des Tresors erzeugt (auf einem normalen Bereich der Festplatte) und habe ein Python-Programm geschrieben, das die Dateien in dieser lokalen Kopie mit dem Inhalt des Cryptomator-Tresors synchronisiert. Das Programm vergleicht im Modus »sync« die Verzeichnisstruktur, prüft das Änderungsdatum und entscheidet dann, welche Datei in welche Richtung zu kopieren ist, und führt diese Operation dann auch aus. Das Programm kann auch den Inhalt des Tresors durch das lokale Verzeichnis ersetzen (»save«), wobei nur solche Dateien in den Tresor geschrieben werden, die dort nicht existieren, oder dort älter sind. Existiert eine Datei im Tresor, die im lokalen Verzeichnis fehlt, wird sie aus dem Tresor gelöscht. Mit »load« macht das Programm dasselbe in die andere Richtung (Der Zustand des Tresors wird ins lokale Verzeichnis kopiert).

Ich öffne seit ich diese Lösung implementiert habe, mit keinem Programm mehr jene Dateien, die im Tresor liegen, sondern mache am Beginn meiner Arbeit mit meinem Programm einen »load«, bearbeite dann die Dateien in der lokalen Kopie außerhalb des Tresors, und wenn ich fertig bin, führe ich mit meinem Python-Programm »save« aus, sperre den Tresor, warte bis OneDrive mit Synchronisieren fertig ist und fahre dann den Rechner herunter. Ich versuche zu vermeiden, mit zwei Rechnern zugleich via OneDrive mit der Cloud verbunden zu sein, weil das meiner Erfahrung nach zur häufigen Bildung von Conflict-Dateien führt.


Ich werde nun meine Sicherungen per USB-Stick auf einem Rechnern zusammenführen und konsolidieren.

Aber was mache ich jetzt mit dem Inhalt des Tresors und seiner verschlüsselten Version in der Cloud? Soll ich das löschen und einen neuen Tresor erzeugen?

Auch wichtig: Worauf muss ich achten, um zukünftige Probleme zu vermeiden?