Kurze Anmerkung bzw Frage zur item.checksum: wird die mit hochgeladen und wenn ja, ist das die checksum der verschlüsselten oder unverschlüsselten Datei? Hoffe nicht letzteres?
Von Roadrunner1234 am Mi, 27. August 2014 um 10:30 #
Verschlüsselte Dateinamen und dann eine Checksummendatei, in der genau der originale Dateiname steht? Da hätten Sie sich aber die Arbeit sparen können - ist ja nur security through obscurty.
Von Roadrunner1234 am Mi, 27. August 2014 um 18:37 #
Dann lies doch bitte noch mal den Artikel und achte mal auf die Stelle, an der beschrieben wird, wie - was - wohin verschlüsselt wird und was genau der Vorteil sei.
...nur, auch ich kann mir leider nicht vorstellen auf einem schlanken (Home-)Server oder auch auf einem NAS Java zu installieren... sorry, aber es gibt einfach Dinge die gehen nicht
Mit schlank meinst du Museumsstücke? Auf einem aktuellen Server mit, sagen wir mal 32G, fällt eine Javaapplikation,wenn sie vernünftig programmiert ist, bestimmt nicht ins Gewicht.
Das mit Java ist nicht unbedingt glücklich, aber insgesamt finde ich das es ein schönes Projekt ist. Ich hoffe es finden sich noch weitere Unterstützter!
wie ich Artikel bereits erwähnt habe ist ein Problem von duplicity das es die Dateien nicht einzeln sondern als komplett Archiv mit anschliessenden Diff's synct.
Ausserdem verwendet duplicity eine seit April 20, 2012 als deprecated gekennzeichnete API von google drive die im April 2015 komplett abgeschaltet wird.
Sollte ja dank Java funktionieren oder?
Ich denke das sollte funktionieren. Hatte nur keine Möglichkeit zum testen.
Würde mich über Feedback freuen und dann entsprechend die Beschreibung anpassen.
Danke für Code und Artikel.
Kurze Anmerkung bzw Frage zur item.checksum: wird die mit hochgeladen und wenn ja, ist das die checksum der verschlüsselten oder unverschlüsselten Datei? Hoffe nicht letzteres?
Ansonsten gute Arbeit!
die checksum ist von der unverschlüsselten Datei. Sie wird aber als Teil der verschlüsselten Metadaten abgespeichert.
Die Metadaten enthalten hierbei.
filetype [folder,file,symlink]
filecontent, filename and original filesize
createtime, modifytime and accesstime
owner, group, posix permissions, acl entries and fat32 attributes
md5 checksum
Verschlüsselte Dateinamen und dann eine Checksummendatei, in der genau der originale Dateiname steht?
Da hätten Sie sich aber die Arbeit sparen können - ist ja nur security through obscurty.
Sollte kein Problem sein, solange sie nicht in der Cloud gespeichert wird.
Dann lies doch bitte noch mal den Artikel und achte mal auf die Stelle, an der beschrieben wird, wie - was - wohin verschlüsselt wird und was genau der Vorteil sei.
Ein No-Go!
Begründung
Eine supper Idee, das Projekt gefällt mir...
...nur, auch ich kann mir leider nicht vorstellen auf einem schlanken (Home-)Server oder auch auf einem NAS Java zu installieren... sorry, aber es gibt einfach Dinge die gehen nicht
immer noch ist keine Begründung für diese Überlegung da ..
also .. macht mal .. Begründung für das Java-Bashing .. ich bin ganz Ohr und Auge ..
Mit schlank meinst du Museumsstücke?
Auf einem aktuellen Server mit, sagen wir mal 32G, fällt eine Javaapplikation,wenn sie vernünftig programmiert ist, bestimmt nicht ins Gewicht.
Geht wunderbar. Mein schlanker Server (Microserver) kann problemlos Java, mein NAS auch. Ansonsten ist ja der Source verfügbar :D.
Das mit Java ist nicht unbedingt glücklich, aber insgesamt finde ich das es ein schönes Projekt ist.
Ich hoffe es finden sich noch weitere Unterstützter!
Warum nicht duplicity? Das kann das schon länger!
wie ich Artikel bereits erwähnt habe ist ein Problem von duplicity das es die Dateien nicht einzeln sondern als komplett Archiv mit anschliessenden Diff's synct.
Ausserdem verwendet duplicity eine seit April 20, 2012 als deprecated gekennzeichnete API von google drive die im April 2015 komplett abgeschaltet wird.