Hallo Icke,
Zu 1: Also die Verunsicherung sollte eigentlich eher durch die aktuelle Implementierung kommen, weil sie halt löchrig ist. Man könnte das Loch ja auch anders stopfen als wie von mir beispielhaft angeführt, auch wenn ich diese Variante für am transparentesten halte und damit für am wenigsten verunsichernd.
Zu 2): Nein, das Chaos lässt sich sehr einfach vermeiden, da eine "Konvertierung" der alten zu den neuen Einstellungen recht trivial sein sollte, weil sich die aktuellen Einstellmöglichkeiten zu 100% abbilden lassen. Nur andersrum wäre es ein Problem, aber da muss man sich überlegen, ob man ein Downgrade der Version wirklich unterstützen möchte. Und selbst das ließe sich mit einer Warnung vor dem "Loch", das u.U. entsteht, transparent machen.
Zu 3) Ja, das ist richtig und ein valides Argument, das einer Änderung im Wege stehen könnte. Hier steht Aufwand gegen Nutzen, klar. Im Zweifel müsste man bei den Sprachen erstmal EN und DE machen und alle anderen nachziehen. Sieht nicht schön aus, wäre aber früher oder später glattgezgogen.
Zum Hinweis mit dem "Beidseitig". Das ist keine Lösung, weil ja gerade
keine beidseitige Synchronisation erfolgen soll und
keine Dateien gelöscht werden sollen. Mein Begriff "inkrementelles Backup" mag irreführend gewesen sein, denn zumindest der entsprechende
Wiki-Eintrag beschreibt das ein wenig anders.
Ich meinte damit folgendes:
- Alles, was sich geändert hat, wird kopiert (im Ziel überschrieben).
- Alles, was hinzugekommen ist wird kopiert.
- Alles, was gelöscht wurde, bleibt im Ziel erhalten.
Letzteres macht natürlich – im Sinne des Backups – ein Zurückspielen schwierig, weil man sich dann den ganzen alten Kram wieder mit rüberholt, den man schon gelöscht hatte. Aber je nach Anwendungsfall ist dieses Szenario nicht relevant, z.B., wenn es um Daten geht, die per se nicht gelöscht werden. Das können z.B. Fotos sein. Diese löscht man vermutlich meist schon auf dem Smartphone, also
vor einer Sicherung. Bei der werden dann also nur die relevanten Fotos gesichert. Später muss dann aber auf dem Smartphone Speicherplatz freigegeben werden, und die ältesten Fotos werdend aher gelöscht. Das darf natürlich nicht dazu führen, dass diese Fotos auch aus dem Backup gelöscht werden. Genau das würde aber bei "Ordner spielgen" und "Beidseitig" aber passieren. Im konkreten Beispiel würde "Ordner sichern" sogar funktionieren, weil Fotos normalerweise nicht geändert werden. Je nach Smartphone-App kann aber auch das leicht passieren, wenn nämlich z.B. nachträglich Tags hinzugefügt werden oder das Bild gedreht wird. Das führt dann zu Duplikaten im Backup.
Im Grunde könnte man das "Problem" vielleicht schon mit einer weiteren Tickbox unter "Ordner sichern" lösen: "Geänderte Dateien im Zielordner überschreiben (keinen neuen Dateinamen generieren)". Damit verliert man die Änderungshistorie, klar. Aber man kann dann entscheiden, ob man die braucht.
Wenn ich mir das jetzt recht überlege, kommt das "Ordner sichern" dem inkrementellen Sichern laut Wiki schon nahe, auch wenn Inkremente nach der reinen Lehre vermutlich in Parallel-Strukturen abgelegt würden. Beim (nicht) Löschen hingegen passt es wieder nicht so ganz
Die Frage ist hier nur:
Wofür wird ein neuer Dateiname generiert? Für die ältere Datei im Ziel (durch Umbenennen dieser) oder für die neue Datei aus der Quelle? Die Frage ist insofern rhetorisch als ich es gleich einfach mal ausprobieren kann. Es wird nur in der Oberfläche nicht 100% klar.
Es bleibt unabhängig davon die Sache mit den Datumsfiltern. Wäre vielleicht eine Überlegung wert, auch wenn man sich damit ein Stück weit in Teufels Küche begibt, weil Dinge wie Zeitumstellung und Zeitzonen eine Rolle spielen können und auch Mini-Differenzen im Zeitstempel. Andererseits spielen die für die Unterscheidung nach Monaten oder Jahren keine Rolle.
