snix sagt

Ich hätte nicht erwartet, dass das funktioniert. Meine Befürchtung war auch, dass die komplette Container-Datei neu übertragen wird.

Vielen Dank für Deinen Test!

Kommentar am 28. März 2009 um 14:08 geschrieben.

Matthias sagt

Danke Caschy!
Geniale Lösung. Bin bisher davor zurückgeschreckt Dropbox zu nutzen. Eben wegen der fehlenden Verschlüsselung (ich trau grundsätzlich nur meiner “eigenen” Verschlüsselung.
So bietet sich das ganze doch wirklich als Backup kleinerer Sachen an.

Kommentar am 28. März 2009 um 14:13 geschrieben.

atreiu sagt

Das wäre ja super, wenn das funktioniert! Nach so eine Lösung suche ich schon wirklich lange, da man damit endlich 100% sicher private Daten auf fremdem Server speichern kann.

Bevor ich das selbst ausprobiere, wäre es schön, wenn jemand eine Erklärung für dieses Verhalten hat

Kommentar am 28. März 2009 um 14:13 geschrieben.

FERNmann sagt

In der Dropbox-Wiki wird diese Vorgehensweise sogar vorgeschlagen: http://tr.im/hV9a
Mich wundert es nur, dass Dropbox die einzelen Dateien im TrueCrypt-Container erkennt. Müssten die Entwickler ja irgendwie absichtlich eingebaut haben.

Kommentar am 28. März 2009 um 14:57 geschrieben.

3lektrolurch sagt

Als Informatik-Laie würde ich mal dazu sagen, dass Dropbox erstmal nur den Fingerabdruck vergleicht und bei Ungleichheit dann einen bit-/byteweisen Vergleich vornimmt, dann bei Bedarf die zu ändernde Datei umbaut, wobei Dropbox gar nicht wirklich weiß, was es da macht, dateimäßig gesehen.
Das dürfte ja nur dann geschehen, wenn die Dateien exakt die gleiche Größe haben und vom Namen her auch gleich sind.

Müßte man mal mit einer Grafikdatei ausprobiern, bei der ein Byte verändert wurde, dann wüßte man ob’s stimmt.

Kommentar am 28. März 2009 um 15:14 geschrieben.

Kamtabia Ysimer sagt

TC Container sollten eigentlich immer die gleiche Größe haben, egal was darin passiert. Also gehe ich auch davon aus das einfach eine Bit für Bit Kontrolle gemacht wird, und nur veränderten Bits/Bytes des Containers übertragen werden. Eine entschlüsselung und Kontrolle der enthaltenen Daten findet wohl nicht statt, wie auch.

Kommentar am 28. März 2009 um 15:20 geschrieben.

Flo sagt

Ich weiss nicht, was ich davon halten soll….

Innerhalb des Containers findet eine komplizierte Verschlüsselung statt. Wenn jetzt bitweise etwas kopiert und im alten (gesicherten) Container überschrieben wird, wird da nicht die existierende Verschlüsselung an irgendeiner Stelle unterbrochen oder verändert?

Kommentar am 28. März 2009 um 16:35 geschrieben.

ich sagt

Caschy, bitte, lass das Buzzword-Dropping. “In der Cloud” ist einfach gruselig. “Online” reicht völlig, ist korrekt, und jeder weiß, was gemeint ist.

Kommentar am 28. März 2009 um 16:42 geschrieben.

3lektrolurch sagt

@flo: wenn Dropbox die Containerdatei immer restlos synchronisiert, wo sollte sich da ein Fehler ergeben? Es wird ja immer von einer funktionierenden Datei ausgegangen.
Probleme könnte es vielleicht geben, wenn eine Syncronisation unterbrochen wird. Dann weiß dropbox vielleicht nicht, welcher der letzte Quellcontainer war. Natürlich ist das immer der auf dem Stick, aber dropbox dürfte wohl immer auch von einer Änderung erst auf dem Server ausgehen…oder soll der User das gar nicht können dürfen? Muß man wohl mal alles testen.

Kommentar am 28. März 2009 um 16:44 geschrieben.

caschy sagt

Ich glaube kaum, dass in diesem Beitrag die besondere Beachtung auf Cloud liegt.

Kommentar am 28. März 2009 um 16:44 geschrieben.

RudiRalala sagt

Den gleichen Effekt gibt es auch mit anderer professioneller Sicherungssoftware. Zwecks Laufzeitoptimierung wird nur eine inkrementelle Delta-Sicherung auf die alte Datei oder auch auf den ganzen Datenbestand durchgeführt.

Den Muster-Abgleich kann man ja auch bei “Hobby-Software” wie Toucan oder SyncToy ein- und ausschalten.

Ich würde davon abraten, auch scheinbar sicher verschlüsselte Dateien online in der Wolke und dann noch in den USA abzulegen. Die Wege des Herrn und der CIA sind unergründlich …

Kommentar am 28. März 2009 um 16:47 geschrieben.

Ren sagt

Bemerkung: Es wird nicht nur die geänderte Datei synchronisiert, sondern auch der Verzeichniseintrag, der innerhalb des Containers gespeichert wird. Da der Container, der 10 MB groß ist, immer 10 MB Platz einnimmt, egal wie viel benutzt ist (Leerer Speicherplatz erscheint als Zufallsdaten) benötigt der Container, nachdem er einen kleine Textdatei beinhaltet, immer noch 10 MB. Ein Teil der Zufallsdaten wird mit der verschlüsselten Version der Textdatei überschrieben. Diese paar Bytes ändern sich in der 10MB großen Datei, und Dropbox synchronisiert sie. Dropbox scheint dabei so intelligent zu sein, dass sie nur geänderte Daten synchronisiert. Warum sie das aber nicht tut, wenn der Zeitstempel des Containers sich ändert, finde ich viel interessanter.
Eine Andere Frage ist: Was passiert, wenn ich auf einem zweiten Rechner gleichzeitig meinen Container ändere. Nach Adam Riese und Eva Zwerg müsste Dropbox dann her gehen, und einen Konflikt melden. Wenn er es jetzt auch noch schafft, den Konflikt innerhalb der Textdatei, die im verschlüsselten Container liegt, zu lösen, dann ist Truecrypt geknackt. *g*

Kommentar am 28. März 2009 um 17:03 geschrieben.

3lektrolurch sagt

@Ren: wenn der Zeitstempel des Containers sich geändert hat ist wohl für dropbox der Fall klar, nämlich die ganz normale Dateiänderung = überschreibe alte Datei (auf Server).
Ich glaube bald zu wissen, warum dropbox die byteweise Angleichung macht. Vielleicht deswegen, weil es bei Dateien, die zwar die gleiche Größe und den gleichen Namen haben, aber einen unterschiedlichen Fingerabdruck, annimmt, dass es sich um einen Übertragungsfehler handelt und die Datei quasi stückweise zusammenschustert, um Traffic zu sparen, vielleicht ja ab einer festgelegten Dateigröße.

Kommentar am 28. März 2009 um 17:20 geschrieben.

Ren sagt

@3lektrolurch: das klingt vernünftig.
@RudiRalala: Ich würde nicht davon abraten, verschlüsselte Dateien auf einem Server in den USA abzulegen. Klar, die von atreiu angesprochene 100%tige Sicherheit gibt es nicht. Aber besser man lädt Dateien in einem verschlüsselten Container auf einen Server in den USA, als im Klartext. Und besser man hat einen Verschlüsseltes Backup seiner wichtigen Daten auf einem Server in den USA, als kein Backup.
Jeder muss für sich entscheiden, was wichtiger ist. Der Dienst, oder die Sicherheit, dass die Daten keiner lesen kann. Wenn man aber den Dienst nutzt, dann doch verschlüsselt. Ist doch ne super Sache! Übrigens: das ganze müsste auch mit Hidden Volumes gehen.

Kommentar am 28. März 2009 um 17:32 geschrieben.

aubriete herzenduft sagt

Natürlich.
Denn WAS in der Datei steckt, ist nach außen so oder so nicht bekannt. Das Backupprogramm sieht nur die einzelnen Bytes. Es weiß ja nicht da da etwas verschlüsseltes ist.

Kommentar am 28. März 2009 um 17:57 geschrieben.

3lektrolurch sagt

@Ren: Gleichzeitig, wie soll das gehen? Wenn auf einem zweiten Rechner enbenfalls die Containerdatei geändert wird, wird der jeweils letzte Synco-Vorgang den vorhergehenden überschreiben…
Eine Sicherheitsminderung der Verschlüsselung könnte ich mir vorstellen, wenn zwei oder mehr aufeinanderfolgende Versionen einer Containerdatei vorliegen. Fängt also jemand den Datenverkehr ab, könnte das erreicht werden und würde erkennen können, wieviele und welche Bytes geändert wurden. Das wäre für den Entschlüssler schon eine vorteilhafte Ausgangslage.
Würde ich wichtige Dateien in einem solchen Container verstecken, käme nur eine Mixtur aus mehreren Verschlüsselungsalgorithmen in Frage, ich bezweifle, dass auch mit diesem Vorteil da irgendeine echte Chance zu Knacken bestünde.

Kommentar am 28. März 2009 um 19:41 geschrieben.

FERNmann sagt

Achso, Dropbox gleicht den Container bitweise ab. Dachte schon, der macht das TrueCrypt Volume irgendwie auf, wie bei ZIPCrypto, wo die Dateinamen unverschlüsselt sind.

Kommentar am 28. März 2009 um 20:25 geschrieben.

Chris sagt

Feine Sache, danke für die Anleitung, das wollte ich schon immer mal ausprobieren. Gleichzeitig habe ich für grössere Backups Jungle Disk und Amazon S3 laufen, da funktioniert das ganze genauso (wenn die Zeitstempel-beibehalten-Option in TC deaktiviert ist, werden nur die geänderten bits übertragen) – sehr effizient.

Mit dem Server in den USA hab ich keine Probleme, aber hier geht es ja sowieso auch um Backup und nicht so sehr um maximale Geheimhaltung.

Kommentar am 28. März 2009 um 20:53 geschrieben.

Lukas sagt

Danke Caschy!
Einfach genial dieser Tip!

Kommentar am 28. März 2009 um 21:28 geschrieben.

Tom sagt

Nur also Info;
Nach dem Lesen des Artikels habe ich mal versucht die portable Version zu starten, aber auf meinem Windows 7 x64 läuft die nicht! Das Programm bricht sofort ab …

UPDATE: Der direkte Aufruf der DROPBOX.EXE scheint zu funktionieren :-O

Kommentar am 28. März 2009 um 21:34 geschrieben.

caschy sagt

Jau, ist ja auch nur 32Bit (wie in verlinkten Beitrag erwähnt).

Kommentar am 28. März 2009 um 21:36 geschrieben.

Tom sagt

Und? Fast alle meine portablen Programme sind nur 32bit (TrueCrypt, Launchy, CCleaner, Console …). Weiß gar nicht, welches ich 64bittig habe …
Ist erst das zweite Mal, dass ein portables Programm Probleme macht – das andere ist Dein portables Chrome!

Interessanter ist wirklich das “Zusammenspiel” von DropBox und Truecrypt! Mir ist ehrlich gesagt nicht klar, WAS da genau abläuft. Muss mal einen Sonntag drüber nachdenken :-O

P.S.: Über Console könntest Du übrigens auch mal was Schreiben (liegt irgendwo unter sourceforge …)

Kommentar am 28. März 2009 um 23:01 geschrieben.

vmk sagt

Die Beschreibung, dass bei neuem Zeitstempel die ganze Datei und sonst nur ein bit/blockweiser Abgleich stattfindet, das hört sie wie eine schon sehr bekannte Sync-Lösung an: rsync – Wikipedia. Das Verhalten von rsync lässt sich durch unzähliche Parameter steuern. Ich denke DropBox benutzt den schon vorhandenen Code von rsync oder eine sehr ähnliche Implementation. Ein Abgleich von z.B. mp3-Dateien mit geänderten ID3-Tags benötigt auch nur ein paar Bits pro Datei.

Kommentar am 28. März 2009 um 23:12 geschrieben.

Joshua ( @jsysde) sagt

Interessant. Ich würde das gern mal mit nem grösseren TC-Container ausprobieren (Benchmark machen), allerdings limitiert z.B. SkyDrive die max. Dateigrösse auf 50MB pro Datei. Wo krieg ich denn ne Datei (also nen TC-Container) hochgeladen, die z.B. 1GB gross ist (oder grösser)?

Kommentar am 29. März 2009 um 14:24 geschrieben.

dermike sagt

Funktionert hervorragen, danke für den Tip

Kommentar am 29. März 2009 um 18:57 geschrieben.

michael sagt

FRAGE
Wo liegt eigentlich der Sinn das ganze mit einem TC-Container zu betreiben, wenn der HOST die Routine zur Entschlüsselung kennt??

Kommentar am 30. März 2009 um 07:15 geschrieben.

3lektrolurch sagt

@Joshua: Skydrive arbeitet doch nicht mit Dropbox zusammen, oder willst du sowas wie rsync oder DeltaCopy nutzen?
@michael: wie kommst du darauf, dass der Host die Routine kennt? Soweit ich das versteh, synchronisiert Dropbox erst, nachdem der Container im normalen lokalen Einsatz war und unmounted wurde, da is nix mehr mit entschlüsseln.

Kommentar am 30. März 2009 um 17:29 geschrieben.

Ich ( @amoklauf_dot_ch) sagt

jo container ist im syncenden zustand ja nicht mehr offen, sondern nur ne einzele datei die schlussendlich aus 0en und 1er besteht.

Kleines Beispiel:

Dein Truecryptcontainer sieht so aus: 001011001110
Nun mountest du ihn und änderst ne Datei.
Zum sichern wird er wieder abgehängt.
Nun sieht dein Container so aus: 101011001111

Dropbox erkennt nun, dass sich da was geändert hat. Er knallt nun nicht mehr die komplette Datei hoch, sondern nur die 2 (die erste und hinterste) Stellen, die sich verändert haben. Dabei geht nix kaputt, da ja dann bei euch zuhause und auf dem Server 1:1 die gleiche Datei ist.

Kommentar am 31. März 2009 um 10:46 geschrieben.

Rainer sagt

Habe Dropbox ausprobiert … und wie erwartet schert sich ein proprietäres Programm nicht um bisherige Konventionen aus der Open-Source-Welt. Konkret: ich nutze TortoiseHG (und früher TortoiseSVN) zur Versionsverwaltung von Quellcode. Das sind schöne Explorer-Erweiterungen, um Mercurial- und Subversion-Repositorys zu verwalten. Diese nutzen, genau wie Dropbox, Overlay-Icons für Dateien, um anzuzeigen, ob eine Datei geändert oder hinzugefügt wurde, im Konflikt steht, aktuell ist, etc.

Dropbox hat dafür dann seine eigenen Icons genommen, anstatt diejenigen aus Tortoise dafür zu verwenden (die beiden Tortoise-Varianten teilen sich nämlich die Icons). Warum ist das schlecht? Weil der Explorer nur 16 Plätze bereithält für diese Icons. Und wenn Dropbox sich welche nimmt, werden andere Icons in Tortoise nicht mehr dargestellt.

Im Endeffekt natürlich eine irrwitzige Einschränkung des Explorers, aber andererseits: Wer als Programmierer so etwas kennt und nutzt (wie bei Dropbox), sollte BITTE sparsam damit umgehen und gemeinsame Plätze teilen.

Kurz gesagt: Tortoise ist mir wichtiger, Dropbox kommt erstmal wieder weg.

Kommentar am 31. März 2009 um 15:06 geschrieben.

Rainer sagt

Wegen den Overlay-Icons: ich hab einfach drei nicht so dringend benötigte von TortoiseHG gelöscht aus der Registry, dann geht’s auch wieder.

Kommentar am 2. April 2009 um 22:18 geschrieben.

Stefan Block ( @sblockde) sagt

Ich benutze Allway Sync zum Syncen der lokalen Daten auf einem Netzlaufwerk. Bekommt man dieses “Feature”, das nur die Änderungen des Containers übertragen werden, dort auch hin? Eventuell auch mit einem anderen Sync-Programm?

Kommentar am 14. April 2009 um 20:07 geschrieben.

3lektrolurch sagt

@Stefan Block: möglicherweise geht das mit DeltaSync. Allway Sync kann das wohl eher nicht.

Kommentar am 14. April 2009 um 22:24 geschrieben.

steven sagt

Super Anregung…..hat Begehrlichkeiten geweckt…ich will ich das Prinzip aber nicht mit Dropbox//Truecrypt, sondern mit meinen eigenen FTP Servern allgemein nutzen.

Jetzt sitze ich schon Stunden um dasselbe Ergebnis hinzukriegen -nur die veränderten Bytes einer Datei werden übertragen statt der gesamten Datei, das wäre soooo schön um beim Hin- & Herschieben von Datein von diversen FTP Servern mal von Tempo reden zu können (trotz 2000MBit upload…).

Der Hinweis mit rsync -was apple auch bei timemachine einsetzt- war schon ganz gut. Leider fehlt der Hinweis auf weitere Software, die das Protokoll ebenfalls nutzt.

DeltaCopy klappt beim Backup über PCs – beötigt aber Installation eines Server-Dienstes (->nur lokales Windowssystem bzw. WinServer mit fester IP).
Unison ist nach Testen (puh..) doch zu langsam überträgt massig Bytes und ist schlecht in der Bedienung.

Hey, wenn hier jemand was dazu weiß : Bitte posten!
Ist ein super Thema und anscheinend auch eine Marktlücke.

Kommentar am 25. April 2009 um 20:22 geschrieben.

penpusher sagt

@caschy

danke für diese ausführliche Anleitung und allgemein für die Dropbox-Tipps.

Ich (Generation 57+) habe es ohne Fehler einrichten können.

Kommentar am 29. Mai 2009 um 18:14 geschrieben.

Thorsten sagt

Kurze Frage:
Die Option “Zeitstempel von Containerdateien behalten” muss an- oder abgehakt sein? Ich verstehe es so, dass die Option angehakt sein soll, bei dir im Screenshot ist diese aber deaktiviert!

Kommentar am 2. Juni 2009 um 18:52 geschrieben.

Andy sagt

Wie groß sind eure Container, die ihr mit Dropbox nutzt?

@Thorsten
Ich glaube es muss deaktiviert sein, aber ich hab grad erst angefangen damit rumzuspielen

Kommentar am 19. Juni 2009 um 23:02 geschrieben.

Joachim sagt

Bei mir ist der Haken drin und es funktioniert scheinbar trotzdem..

Kommentar am 8. Juli 2009 um 20:28 geschrieben.

bertyX sagt

ja das ist in der Tat verwirrend, da ja der Haken per DEFAULT gesetzt ist und gestzt bedeutet, dass per DEFAULT das Datum bei jeder Änderung NICHT geändert wird.

Wenn man den Haken wegnimmt, dann meckert TrueCrypt, dass das Weglassen ein Sicherheitsrisiko darstellt ( logisch ) und dann wird das Datum angepasst.

Was muss man nun machen? ich lad mein container gerade hoch und hatte keine Gelegenheit zum testen

Kommentar am 9. August 2009 um 22:48 geschrieben.

bertyX sagt

also habs jetzt getestet und ohne den haken ist es für den Zweck wohl richtig, wobei dass dann nicht mehr zur Erklärung passt

was ich nicht kapiere ist, wieso dropbox erst anfängt zu syncen wenn das gemountete file dismountet wird ?! truecrypt verschlüsselt doch on the fly …

Kommentar am 9. August 2009 um 23:39 geschrieben.

er sagt

Buzzword-Dropping = Buzzword-Dropping

Kommentar am 13. August 2009 um 19:43 geschrieben.

Patrick sagt

Kann mir vielleicht wer sagen, ob ZumoDrive auch nur die geänderten Bytes einer Datei übertragen soll, oder immer komplett?
Bei mir scheint es so zu sein, egal ob ich in TrueCrypt “Zeiteinstellungen von Containerdateien behalten” an oder aus habe, es wird mit ZumoDrive immer der ganze Container übertragen. Wie ist das bei euch?

Kommentar am 26. August 2009 um 18:53 geschrieben.

Christian Ulbrich sagt

Also, im Gegensatz zum Artikel, bewirkt die Einstellung gerade, dass sich der Zeitstempel für die Datei verändert; was Dropbox dann auch dazu veranlasst, eben einen Vergleich mit der vorhandenen Version zu machen und dann nur die Änderungen zu übertragen.

Wie TrueCrypt schon richtig darauf hinweist, ist diese Einstellung ein Sicherheitsmangel – denn nun wissen, entsprechende Dritte, dass sich zu einem Zeitpunkt etwas geändert haben muss.

Die Daten sind übrigens, so der Container auch mit einem guten Passwort verschlüsselt sind, dann in der Tat bei Dropbox selber sicher; sprich, jeder der die Übertragung hin zu Dropbox abhört, bzw. Dropbox selber kann mit dem verschlüsselten Container nix anfangen.

Wie schon vermutet, verwendet Dropbox einen Delta-Algorithmus, der eben nur die geänderten Teile einer Datei überträgt. Wenn man nun im TC-Container einzelne Dateien ändert, dann ändern sich eben auch nur einzelne Bereiche der eigentlichen Containerdatei, und deshalb werden auch nur diese Änderungen übertragen. Wer übrigens Paranoia schiebt, dass Dropbox an seinem verschlüsselten TC-Container herumschnüffelt, der sollte viel mehr Kraft in die Absicherung des eigenen Rechners investieren (keine Adminrechter, nicht jedes Programm starten), da lauern mehr Gefahren (Trojaner, Keylogger).

Kommentar am 27. August 2009 um 21:47 geschrieben.

Ick sagt

@C.Ulbrich: Falsch, der Haken MUSS gesetzt sein, das Datum soll NICHT geändert werden. Ändert sich das Datum wird der komplette Container übertragen, wenn nicht, überprüft Dropbox nur den Fingerabdruck der Datei und überträgt die einzelnen kleinen Änderungen.

@All: Weiß einer ein Programm mit dem sich selbiges auch mit einem eigenen FTP-Server realisieren lässt. Mein 500MB-TC-Container läuft bisher über die Dropbox, allerdings lässt die Performance von Dropbox gefühlt etwas nach. Vor allem morgens und abends, was natürlich logisch ist, aber dennoch nervt.

@All2: Steigt die Geschwindigkeit in der gekauften Version, ist die Freeware also gedrosselt?

Kommentar am 2. September 2009 um 10:54 geschrieben.

caschy sagt

@ick

Unter Windows kannste FTP-Server mit Laufwerksbuchstaben mappen. Such mal hier im Blog

Und nein, nix gedrosselt, nur Space.

Kommentar am 2. September 2009 um 10:58 geschrieben.

Ick sagt

@caschy: Danke, dann lohnen die 10$ also erstmal nicht.

Ich nutze für meine normalen Backups z-dbackup, allerdings lässt sich dort die Dropbox-Variante (TC Container, nur Änderungen auf FTP-Server übertragen) nicht verwirklichen.
Ich will den FTP-Server nicht als LW einbinden, sondern das soll ohne gehen, eben wie bei Dropbox. Jemand ne Idee bzw. nen Softwarevorschlag? Oder steh ich uffm Schlauch? Kann ja mal hüpfen.

Kommentar am 2. September 2009 um 11:54 geschrieben.

Steven sagt

Hi,

weil bei mir ähnliche Begehrlichkeiten nach dieser super Funktion geweckt wurden -nur die veränderten Bytes übertragen, weil die uploadrate meist grauselig ist- hab ich mittlerweile einige Stunden dafür rumprobiert mit diverser Software.

Dropbox -und auch Humyo- beherrschen Differenzübertragung beim Synchronisieren definitiv.

Ein 1,5 GB großer TrueCrypt Container wird nach Ändern von nur einer klitzekleinen txt Datei darin mit dieser Methode super schnell aktualisiert.
Habs mit Humyo sogar mit 4GB probiert….klappt!
Das Sychronisieren ist trotz geringer Uploadrate (relativ) schnell.

Ich möchte das aba ebenfalls mit eigenem Webspace auch so können….

Da man eigenen WebDAV & FTP Speicher mit Teamdrive einbinden kann, lag Teamdrive für mich als Lösung nahe.
Hab also dort angefragt: Teamdrive kann es leider (noch?) nicht.

Meine Tests mit Deltacopy haben Folgendes ergeben:

Was beim RSYNC Protokoll passiert ist, dass die Dateidifferenzen gecheckt werden und Traffic nur für dieses Checken und die Übertragung der Differenzen erzeugt wird -weshalb eine Synchronisierung mit geringen Uploadraten gar nicht anders möglich ist als mit RSYNC Tools.
Die Datei(en) werden allerdings jeweils komplett neu geschrieben.
Das Ganze dauert also mind. solange wie Checken plus Schreiben beansprucht.

….bis ein 4GB Container serverseitig fertig neu geschrieben ist, braucht es also schon relativ lange, auch wenn die Veränderung ingesamt nur 2KB war – und solch eine HDD Auslastung freut den Web-Administrator sicher riesig .

Vielleicht klappt es ja mit dem eigenen Webspace//FTP-Space doch irgendwie mit Deltacopy ? (dabei: muss dies ein Windows server sein?)
Ich hatte noch nicht die Zeit dies zu testen.

Vielleicht kennt sich ja hier jemand aus?
Würd mich über Rückmeldungen freuen!

Kommentar am 2. September 2009 um 19:38 geschrieben.

vNazhas sagt

Mit Dropbox lassen sich auch wunderbar dynamische Container abgleichen.
Hauptsache der Zeitstempel der Datei wird nicht geändert. *g

So kann man sich schonmal die ganzen 2 freien GB belegen.

Kommentar am 16. September 2009 um 02:42 geschrieben.

pedalman ( @Tobias) sagt

Also,

da diese wirklich tollen Programme ja alle nur wenig Speicherplatz zur Verfügung stellen, würde ich tatsächlich auch dafür bezahlen. Ich glaube 9$ sind es bei Dropbox für 100GB. Das wäre ausreichend für meine Bilder und Daten.

Teamdrive wäre auch gut, wenn es dieses DeltySyncing wirklich untersützen würde, denn dann könnte ich ja meinen 1&1 WebDav Space nutzen. Ich habe versucht diesen mit AllWaySync zu nutzen aber ohne DeltaSyncing macht es KEINEN Sinn, wenn man den Speicherplatz zum Syncen nutzen mag und nicht nur als Backup.

Wenn wir zB. unsere Urlaubfotos mit einem der erwähnten tools auf Arbeitsrechner und Laptop verteilt haben (sync) und meine Freundin dann am Laptop Änderungen vornimmt (entweder am Bild selbst oder sogar mit AcdSee Datenbankinfos in die Bilder schreibt, denn nur so kann man einigermaßermaßen an verschiedenen PC mit den Bildern arbeiten), dann macht nur DeltySyncing Sinn, wenn man abschließend alle Bilder abgleichen will.
Ich nutze bisher Syncplicity, das gut funktioniert aber KEIN DS unterstützt, obwohl ewig versprochen.

Zudem hat DropBox nun die beta Funktion, im LAN schneller, dh. direkt per P2P, zu syncen.
Funktioniert nur irgendwie bei mir nicht. Wäre aber ein weiterer riesen Pluspunkt!!!

Dann gibt es noch Powerfolder. Soll auch all diese Funtkionen haben. Hab ich aber lange nichts mehr von gehört.

Weiterhin finde ich gut, dass DropBox sich wenig bemerkbar macht im System. Hintergrundressourcen und sogar eine portable Version gibt es. GLaube Powerfolder nimmt sehr viel und Teamfolder noch mehr an Ressourcen. Synplicity geht.

Wie seht ihr das? Wenn ihr zahlen würdet, welchen Dienst würdet ihr nehmen?

PS:
Zum Thema TrueCrypt. Bekomme die Meldung, Container sei in Benutzung, wenn ich ihn abmelden will und muss ‘force’ anwenden. Habe bisher die install Versionen von DropBox 0.7x und TrueCrypt und nicht die portablen, da ich glaube am PC selber ist das von Vorteil.

Kommentar am 21. September 2009 um 09:58 geschrieben.

HJE sagt

Hallo,

funktioniert auch mit ZumoDrive.

Echt klasse.

CIAO

Kommentar am 17. Oktober 2009 um 09:37 geschrieben.

pedalman sagt

Ich bekomme es nicht hin, dass ich an zwei Geräten die Daten in dem TC Container ändern kann und somit eine Syncronsierung hätte. Ich kann nicht an zwei Rechnern z.B. den Ordner EigeneDatein in den TC Container verlinken. Klappt einfach nicht. Geht immer nur auf einer Seite.

Kommentar am 17. Oktober 2009 um 11:21 geschrieben.

HJE sagt

TC kann (bzw. sollte) auch nur einmal geöffnet sein.

Kommentar am 17. Oktober 2009 um 14:25 geschrieben.

pedalman sagt

Richtig,

aber es geht um die Softlinks unter Windows XP. Auf meinen Rechner haben die Arbeitsaccounts alle den selben Namen und die Dateien liegen in den selben Ordner. Falls das eine Rolle spielt.
Aber sobald ich eine link Kette wie diese aufbaue auf Rechner1:
EigeneDateien = ED :
TrueCrypt Container = TC
DropBox Ordner = DB

ED (auf PC1)-> ED in TC (Der in DB ist)

dann werden Änderungen in ED gespiegelt übernommen in dem Ordner ED, der im geöffneten TC liegt.

Öffne ich diese TC an PC2, dann sollten diese Änderungen von ED in geöffneten TC zum ‘fixen’ Ordner ED in PC2 gespiegelt werden. Das geht, wenn ich die Kette so aufbaue:

ED (in TC) -> ED (auf PC2)

ABER wenn ich nun am PC2 arbeite und Dateien sich ändern in ED (PC2), dann werden diese nicht zurückgespiegelt, denn die obige Kette wirkt nur in eine Richtung. Damit habe ich keine Syncronisationsfunltion.

Kommentar am 19. Oktober 2009 um 09:02 geschrieben.

max sagt

Hallo die Idee mit Truecrypt und Dropbox klingt sehr anregend. Ich habe 1TB 1&1 SmartDrive Speicherplatz und würde gerne damit ähnliches umsetzen.
Wäre folgender Aufbau realisierbar:
1. Daten in TrueCrypt Container auf der eigenen Festplatte
2. Kopie des Kontainers auf 1&1 SmartDrive
3. Synchronisierung des Containers mittels SyncBackSE

wäre damit ein inkrementeller Upload möglich?? Ich glaube SyncBackSE uunterstützt dies, die größere Frage ist, wie sich 1&1 WebDav Lösung verhält?? Hat jemand Erfahrung damit??

Kommentar am 26. Oktober 2009 um 17:04 geschrieben.

komalot sagt

Ist es denn eigentlich normal, dass Dropbox nicht auf den Container zugreifen kann, bis man das Volume wieder trennt in Truecrypt? Dropbox meldet im Status “Can’t sync (Datei); File in use”. Bei nicht verschlüsselten Daten geht ja alles immer sofort.

Und ein Hinweis: Habe gerade die aktuelle Version (6.3) geladen, mittlerweile ist die Zeitstempel behalten – Funktion standardmäßig aktiviert.

Vielen Dank für die Anleitung!

Kommentar am 13. November 2009 um 10:43 geschrieben.

kraymer sagt

Vielen Dank für den Beitrag,

ich erhalte von Truecrypt beim Mounten jedoch von Truecrypt die Fehlermeldung, dass die Datei (“The host file is already in use!”) bereits verwendet wird.

Sobald ich die Dropbox Anwendung schließe, kann Truecrypt die Datei problenmlos mounten. Verhält sich Truecrypt bei Euch ähnlich?
Ich finde es nämlich ein bisserl umständlich, wenn ich jedesmal, wenn ich den Container nutzen möchte vorher Dropbox ausschalten muss.

Kommentar am 5. Dezember 2009 um 12:22 geschrieben.

komalot sagt

Nein, habe mit der aktuellen Version (6.3a glaube ich) & Truecrypt dein beschriebenes Problem nicht. Nur der Container wird erst auf den Server geladen, wenn Truecrypt wieder den Container trennt.
mfg

Kommentar am 6. Dezember 2009 um 18:11 geschrieben.

Peter sagt

Habe ich das richtig verstanden, du hast deinen Truecrypt-Container in x Teile zu je 10MB gesplitet? Oder hast du x Container zu je 10MB erstellt.

Wen ersteres zutrifft, wie teile ich einen Container? Hab da keine Option gefunden. Ich denke es ist reichlich unproduktiv x Container zu 10MB anzulegen…

Wenn ich vollkommen falsch liege, dann lasst es mich bitte wissen.

Kommentar am 2. Januar 2010 um 18:15 geschrieben.

Holger sagt

hallo,
vielleicht kann mir hier ja jemand kurz helfen.
ich habe auf meinem mac zu hause einen container in dropbox erstellt.
nun wollte ich per truecryt auf dem mac in der arbeit auf den container zugreifen und dies funktioniert aber nicht. ich bekomme immer die fehlermeldung: “invalid argument”.

vielen dank.

Kommentar am 20. Januar 2010 um 10:18 geschrieben.

Aaron Digulla sagt

VORSICHT: Die ganzen Links zu TrueCrypt auf dieser Seite führen zu einer Seite, wo man einen nutzlosen Vertrag über EUR 84,-/Jahr abschliesst, wenn man die Software dort runterlädt!

Wenn ihr drauf reingefallen seid, dann wendet euch an eure Verbraucherzentrale, die können euch sagen, wie man da wieder rauskommt.

Kommentar am 1. März 2010 um 20:51 geschrieben.

Havoc sagt

Es scheint das dieser Trick in der neuen Version nicht funktioniert.

Ich habe mir extra ein Script gebastelt was das für mich automatisiert aber Dropbox will jetzt den Container nicht mehr aktualisieren

EDIT: Hm Dropbox springt erst an wenn man den Container während Dropbox läuft verändert

Kommentar am 3. März 2010 um 17:57 geschrieben.

ani sagt

ein super Programm

https://www.dropbox.com/referrals/NTk0ODA3Njk

Kommentar am 6. März 2010 um 14:06 geschrieben.

Paddy sagt

Thx!
Neuer Dropbox Account? Referral:
https://www.dropbox.com/referrals/NTgzOTc2ODk

Kommentar am 8. März 2010 um 16:08 geschrieben.

Harald sagt

Genialer Tipp! Hat bei mir super funktioniert.
ansonsten biete ich mit diesem Link 250 MB für mich und Euch mehr
Grüße

https://www.dropbox.com/referrals/NTUyMDE1OTg5

Kommentar am 14. März 2010 um 18:15 geschrieben.

Stefan Block ( @sblockde) sagt

Hat das schon jemand mit der neuen Paket HiDrive von Strato hinbekommen? Mir will das nicht gelingen… Zumindest mit rsync unter Linux und AllwaySync unter Windows nicht.

Kommentar am 2. April 2010 um 17:06 geschrieben.

Ich sagt

Das kann doch gar nicht funktionieren? Wie will die Software erkennen, dass sie irgendwo ein Bit geändert hat, wenn sie nicht jedes Bit vergleicht?
Aber genau das kommt doch der Übertragung der kompletten Datei gleich. Kann mir das bitte jmd. erklären.

Kommentar am 8. Mai 2010 um 17:09 geschrieben.

steven sagt

an Ich & Ich
Tja, wie will die Software das erkennen?
Ich habs so recherchiert (…und hoffe das ist korrekt):
Es werden eindeutige Prüfsummen von Teilen der Datei gebildet.
Wenn man eine Datei immer weiter “teilt” (natürlich ist nicht wirkliches physisches Teilen gemeint, sondern nur Abrattern der Datei) bzw. das oft genug macht, findet man ziemlich schnell heraus wo die veränderten Bits der Datei lokalisiert sind.
Nur diese werden dann übertragen.
Trotzdem : auf der Gegenstelle auf dem Server oder sonstwo muss (muss? – das passiert zumindest in der praxis) die Datei wieder komplett neu zusammengebaut werden.
Daher ist es mit sehr großen Dateien dann auch nicht mehr so witzig und wirklich schnell.

Strato HiDrive:
fand ich zu simple, da fehlen Features, hab ich wieder abbestellt. Teanmdrive, Humyo und Dropbox finde ich deutlich besser.
Leider hat Teamdrive (immer noch) kein RSYNC, sonst wäre es mein Favorit.

Ich glaub es nicht…….und schon wieder meint hier jemand alle hätten grade nur auf seinen Dropbox Werbelink gewartet….

Kommentar am 8. Mai 2010 um 17:34 geschrieben.

lx sagt

Hi,
super Sache. Bin zufällig auf diesen Beitrag gestoßen und er lieferte mir genau die Lösung für das problm ean dem ich gerade herum grüble!

Echt klasse Sache

Kommentar am 28. Mai 2010 um 12:26 geschrieben.

Chris sagt

Hey,
wurde inzwischen eine Möglichkeit gefunden das ganze mittels einer alternativen Software über den eigenen Webspace laufen zu lassen?
Ich bin nämlich auch dringendst auf der Suche.
Wär der Hammer!

Kommentar am 27. Juni 2010 um 23:30 geschrieben.

dierk sagt

hallo caschy!
eine DAU-Frage: was muß ich denn jetzt beim Zeitstempel-Kästchen machen: Haken setzen oder wech?
Im Englischen ists mir ja klar – preserve meint aufheben, aber bei Windows würde meiner Interpretation nach ein Haken setzen bedeuten, den ursprünglichen Zeitstempel (unverändert) zu behalten…???
Habe einen 750MB-Container eingerichtet und möchte auf meiner 3Tausender-DSL-Leitung nicht wirklich ausprobieren, was was bewirkt… Danke für Deine Antwort!

Kommentar am 6. Juli 2010 um 15:56 geschrieben.

margin-auto sagt

Vielen Dank für diesen Test und den Hinweis. Habe ich eben bei mir nachvollzogen und es funktioniert!
Ich hatte kürzlich den gleichen Versuch mit UbuntuOne gemacht und hier scheint dieses “partielle Abgleichen” (oder wie man es nennen will), *nicht* zu funktionieren. Es wird dort offenbar in jedem Fall immer der komplette Container hochgeladen, auch wenn der Haken bei “Preserve time…” in TC gesetzt ist
Hat noch jemand das mit UbuntuOne probiert und kann das bestätigen (oder wiederlegen)?

Kommentar am 29. Juli 2010 um 14:25 geschrieben.

heiner sagt

@steven:

Supper recherchiert/gewusst.

Aber mit einem Teil von Deiner Nachricht bin ich nicht so ganz einverstanden.
Es stimmt, man kann einen Truecrypt Container (virtuell) zerteilen und die Prüfsummen der beiden Teile übertragen und vergleichen. Die Zerteilung findet nur virtuell statt. Wenn sich nur ganz wenig im Container verändert hat, hat man schon die eine Hälfte aussortiert. Den anderen Teil kann man dann wieder halbieren (virtuell natürlich) und man hat dann nur noch 25 % zu bearbeiten und so weiter. Nach Zehn Schritten hat man 99.9 % aussortiert. Sind mal bei einem solchen Vergleich beide Teile unterschiedlich in der Prüfsumme, z.B. weil im Container halt doch an mehreren Stellen was geändert wurde, dann muss man entsprechend diese beiden Hälften separat weiterverfolgen.

Das kann man natürlich nicht nur mit Truecrypt Containern machen, sondern mit jeder Datei.

Irgendwann hat man dann eine Liste von ganz kleinen Abschnitten, die unterschiedlich sind. Diese sind dann z.B. 1 KByte gross, denn noch feiner zu suchen erzeugt nur zu viel Overhead.

Man lädt dann nur noch die veränderten Blöcke zum Server hoch, zusammen mit der Info, welche das sind. Die übertragene Datenmenge ist dann nur ein bischen größer als die geänderten Blöcke.

(Ich hab das jetzt mal andersrum geschrieben, weil zwei verschiedene Erklärungen vielleicht noch mehr Klarheit schaffen.)

Wo ich aber noch eine Anmerkung habe, ist daß auf dem Server dann die Datei neu geschrieben werden muss, indem die nicht veränderten Blöcke der Originaldatei mit den soeben hochgeladenen kombiniert werden.

Das macht man in der Praxis gerne, weil man als Programmierer der Software dann sicherstellen kann, dass wenn was schief läuft, man immer noch zumindest die alte Version des Containers hat. Das kann passieren, wenn zum Beispiel die Verbindung abbricht, die Festplatte im Server voll läuft oder dem Server der Strom ausfällt. Man löscht dann halt die unvollständig geschriebene Version des Containers und zeigt dem User an: “Ging nicht.”.

Theoretisch könnte man auf dem Server die hochgeladenen Blöcke direkt in den Container eintragen. Bricht der Vorgang ab, hat man einen inkonsistenten Container, und keine ‘vorherige Version’. Eine Möglichkeit wäre, die Blöcke, die man im Container überschreibt, einfach vorher wegzuspeichern. Dann kann man nach einem Fehler die Vorgängerversion zumindest rekonstruieren. Da muss man aber das Caching auf dem Server gut beherrschen, sonst kann’s passieren dass bei einem Server Crash die weggespeicherten Blöcke es nicht auf die Festplatte geschafft haben. Datenbanken haben deshalb Transaktionen.

Eine andere Lösung wäre, serverseitig gar nicht erst die aktualisierte Containerdatei zu rekonstruieren, sondern die hochgeladenen Blöcke samt Info welche das sind in einer separaten Datei zu speichern. Man nennt sowas dann “Delta Datei”. Es sammelt sich dann auf dem Server dann die erste Version des Continers, plus alle Deltas bis zur aktuellen Version an.

Wird die aktuelle Version dann abgerufen, muss diese dann aus den ganzen Deltas on-the-Fly rekonstruiert werden. Der Vorteil ist aber, dass man auch genauso einfach eine frühere Version abrufen kann.
Übrigens machen das so auch virtuelle Machinen (VMWare, VirtualBox, etc) mit den Festplatten Images. Es gibt eine erste Version und mehrere Deltas, und das Guest OS sieht die on-the-Fly rekonstruierte aktuelle Version.

Irgendwann werden die Online Storage Dienste das auch anbieten.

Hoffe das war nicht zu lang.

Kommentar am 16. August 2010 um 23:10 geschrieben.

Steven sagt

@heiner

War (für mich) definitv nicht zu lang, vielen Dank für die Infos!
Endlich find ich mal jemand der sich auskennt.

Hab mir alles mühsam zusammegesammelt, denn gerade diese Delta Datei Geschichte -Abspeichern und Übertragen- find ich äuerst interessant & sehr brauchbar.
Mich wundert übrigens, dass diese Technik nicht viel mehr angewendet wird.
Mögliche Antwort: “Speicherplatz verkaufen ist viel lukrativer als ihn einzusparen…”

Beim Übertragen ala Dropbox usw. siehts dann halt schon anders aus, denn wer hat schon fette uploadraten? Da muss dann effizient Übertragen werden um die User nicht zu vegraulen.

Vielleicht hast Du ja einen Tip für dieses (sehr verwandte) Thema:
http://stadt-bremerhaven.de/ti.....-timeline/

Ich suche nämlich:
1) eine Backupsoftware mit Versionierung via Delta Dateien
2) eine Systemimagesoftware mit Versionierung via Delta Dateien
(Bislang hab ich nur arcea gefunden)
Die Hersteller schweigen sich lustig drüber aus, was sie genau anbieten – und mich kostet das Testen dann sehr viel Zeit.
Bsp.: selbst das kostenpflichtige Acronis True Image nennt sein Backup zwar “inkrementell”, schreibt aber alle geänderten Files komplett zu 100% neu, macht also zwar “Versionierung”, aber dummerweise wird keine Differenzspeicherung angewendet.
Ist also ein richtig übler Speicherfresser, wenn man sehr große Files regelmäßig sichern will.

Kommentar am 17. August 2010 um 00:28 geschrieben.

TheCoon sagt

Nur für die Annalen und um es zusammen zu fassen (auch damit ich es hier ggf. wieder finde):

Haken muss gesetzt sein und Dropbox muss bei der Befüllung des Containers laufen, sonst funktioniert es nicht (Aktuelle Version 7.0a)!

Klasse Geschichte, Cashy! Danke …

Kommentar am 14. September 2010 um 17:41 geschrieben.

silverhair sagt

Hallo,

das Problem mit der Containergröße ergibt sich nur, wenn gleichzeitig TC-portable im Container ist, richtig?

Meine kdbx ist < 35 KB. Es reicht also ein Container mit Mindestgröße von 292 KB.

Lasse mich gern korrigieren.

Kommentar am 20. Oktober 2010 um 17:32 geschrieben.

DonHæberle ( @donhaeb) sagt

Besten Dank für die Info nachträglich und auch für die Infos in den Kommentaren!

@caschy: Kannst du pipimans frühpupertären Unsinn evtl. entfernen? So etwas muss ja trotz der amüsanten Kommentarnummer nun nicht unbedingt sein, oder?
(Dieser Absatz kann wg. des Links danach natürlich entfernt werden)

Kommentar am 5. November 2010 um 23:28 geschrieben.

DonHæberle ( @donhaeb) sagt

Das ging flott.

Kommentar am 5. November 2010 um 23:31 geschrieben.

DonHæberle ( @donhaeb) sagt

Wann nicht?

Kommentar am 5. November 2010 um 23:34 geschrieben.

Stephan ( @stephan1707) sagt

Ist das noch immer so, dass der gesamte Container neu hochgeladen werden muss?
Ich glaube nämlich nicht.
Ich habe nämlich diese Option nicht eingeschaltet und musste noch nie immer den gesamten Container hoch laden. Ich habe einen 200MB Container, bei dem der gesamte Upload bei ~40kB/s über 1h 25min dauern würde.
Ich habe in diesem Container gerade Testweise 2MB geändert und der Upload ging innerhalb von 1 min über die Bühne.

Gerade auch mal mit aktivierter Option gemacht. Kommt das gleiche bei raus. Upload dauert nur so lange, bis die entsprechend geänderte Datenmenge benötigt, sprich bei 4MB z.B. 2,x min.

Ich nutze die aktuellsten TrueCrypt und Dropbox Versionen.

Im allgemeinen ergibt das ja auch keinen Sinn, dass wegen des Datums die komplette Datei hochgeladen werden müsste. Mein Miranda-Profil ändert auch mit jedem schließen von Miranda das Änderungsdatum und es wird trotzdem immer nur das Delta gesynct. Nie das ganze Profil (das Profil ist über 20MB groß). Das wäre ja der gleiche Sachverhalt.

Kommentar am 1. Dezember 2010 um 14:48 geschrieben.

tilman ( @dotnetpro_mag) sagt

Wenn man der Doku von Dropbox glauben darf, verschlüsseln die die Daten sowieso. Also eher doppelt gemoppelt.
Außerdem übertragen die nur einzelne Datenpakete, die sich geändert haben, also nicht mehr die gesamte Datei.

Kommentar am 17. Dezember 2010 um 15:46 geschrieben.

DonHæberle ( @donhaeb) sagt

@tilman:

Wenn man der Doku von Dropbox glauben darf, verschlüsseln die die Daten sowieso. Also eher doppelt gemoppelt.

Jein. Die Daten mögen zwar mit der Verschlüsselung durch Zugriff von außen gesichert sein, es besteht jedoch auch die Möglichkeit, dass Amazon (auf deren Servern alles gespeichert wird) sie mit Hilfe eines Masterkey wieder entschlüsseln kann.

Kommentar am 17. Dezember 2010 um 16:15 geschrieben.

tilman ( @dotnetpro_mag) sagt

@DonHæberle Ah, okay, dass wusste ich nicht.

Kommentar am 17. Dezember 2010 um 16:55 geschrieben.

zwiebel sagt

@tilman
ist das nun Fakt, dass nicht alles übertragen wird. Hat das jemand getestet?

Kommentar am 17. Dezember 2010 um 17:12 geschrieben.

Sebi ( @Sebastian__1992) sagt

Seit kurzem funktioniert keine portable Version von Dropbox mehr richtig bei mir. Hat jemand die 1.0 als portable am besten ohne .net?

Kommentar am 21. Dezember 2010 um 12:04 geschrieben.

Flo sagt

Hallo caschy – zunächst mal Danke für einen wirklich tollen Blog , den ich mittlerweile eher und sehr gerne als zentrales Informationsportal nutze und insbesondere für diesen Tip.

Eine Frage habe ich: Wenn ich Dateien in den Dropbox-Container kopieren möchte, kann ich dies über das über den in den Arbeitsplatz eingebundenen Ordner tun. Da mir das zu umständlich ist, habe ich eine Verknüpfung in meine Dropbox gespeichert und muss nun nur noch die Dateien da drauf ziehen. Ist das so praktisch wie ich glaube oder eine potentielle Hintertür zu meinem COntainer? Danke, Flo

Kommentar am 11. April 2011 um 18:19 geschrieben.

Timo sagt

Habe nach truecrypt dropbox gesucht und erwartet, dass diese Seite als erstes kommt. Im Nachhinein war ich überrascht über die Selbstverständlichkeit, das ich diese Seite erwartet habe. Aber die Infos sind halt klasse. Spart die eine oder andere Computerzeitschrift. Vielen Dank für deine Beiträge über Jahre hinweg.

Kommentar am 18. April 2011 um 11:40 geschrieben.

Justus sagt

Interessant. Aber leider nicht zu gebrauchen, um die ganze Dropbox zu verschlüsseln, wenn (ja, wenn!) man einzelne Dateien davon mit seinem Mobiltelefon synchronisieren möchte oder einfach nur unterwegs sehen möchte, welche Dateien gerade in der Dropbox sind (ohne sie tatsächlich zum Telefon übertragen zu wollen).

Kommentar am 20. April 2011 um 14:43 geschrieben.

Der Knipser sagt

Ich scheine wohl etwas überlesen zu haben. Wie richte ich denn TrueCrypt mit der bestehenden Dropbox/Dropbox-Ordner ein? Wie in der Anleitung beschrieben http://stadt-bremerhaven.de/mi.....unterwegs? Den Truecrype-Container dann in die Dropbox verschieben und danach die Dateien in der Dropbox, die verschlüsselt werden sollen, da rein?
Der Ordner hat eine Größe von ca. 650 MB.
Ich stehe da momentan etwas auf dem Schlauch…

Kommentar am 10. Mai 2011 um 12:28 geschrieben.

DonHæberle ( @donhaeb) sagt

@Der Knipser: Du nimmst deinen Truecrypt-Container und schiebst ihn in die Dropbox. Die zu verschlüsselnden Dateien legst du dabei in diesen Truecrypt-Container. Für Dateien, die außerhalb dieses Containers in die Dropbox gelegt werden, ändert sich nichts.

Kommentar am 10. Mai 2011 um 12:36 geschrieben.

Thomas Schewe ( @thosch66) sagt

Die Lösung aus Dropbox & TrueCrypt läuft nur solange gut, wie man den TrueCrypt-Container immer nur auf einem Rechner offen hat.

Aber so nutze ich die Dropbox nicht. Wenn ein zweiter Rechner ins Spiel kommt, kann es ganz schnell lustig werden…

-> http://thoschworks.de/blog/?p=854

Kommentar am 12. Juni 2011 um 17:56 geschrieben.

Martin sagt

Hallo miteinander,

ich wuerde gerne meine Dropbox-Dateien wie beschrieben mit TrueCrypt verschluesseln. Allerdings nutze ich Dropbox auch auf dem iPhone, wo ich die verschluesselten Dateien nicht mehr lesen koennte.

(Z.B:
http://forum.golem.de/kommenta.....,read.html)

Gibt es hierfuer eine Loesung? Laeuft TrueCyrpt irgendwie auf dem iPhone?

Gruss,

Martin

Kommentar am 20. Juni 2011 um 21:37 geschrieben.

Thomas Schewe ( @thosch66) sagt

@Martin

Apple sieht nicht vor, dass man Hintergrundprozesse wie z.B. TrueCrypt laufen lässt. Darüber hinaus werden die Prozesse streng von einander getrennt, sodass eine entsprechende Funktion regulär nicht realisierbar ist.

Ob es für gejailbreakte Geräte entsprechende Tools gibt, weiß ich nicht, vermute aber mal nein.

Ich nutze auf meiner Dropbox auch Verschlüsselung (aber nicht TrueCrypt, siehe Kommentar über Deinem), aber nicht für alle Dateien. Vertrauliche Daten kommen in den verschlüsselten Teil und sind auf meinen iOS-Geräten nicht verfügbar. Der Rest liegt “ganz normal” auf der Dropbox und kann auch mit den mobilen Geräten genutzt werden.

Kommentar am 21. Juni 2011 um 02:01 geschrieben.

Martin sagt

@Thomas, vielen Dank fuer die Antwort. Nach dem Vorfall bei Dropbox letzte Nacht, werde ich alle meine Dateien jetzt per Truecrypt verschluesseln. Da ist mir die Erreichbarkeit per iPhone weniger wichtig als die Datensicherheit. Schon unglaublich, was die sich da geleistet haben.

Kommentar am 21. Juni 2011 um 19:01 geschrieben.

Robin sagt

Erst mal danke für den Beitrag!!! Der ist total super.

Habe es jetzt mal ausprobiert. Einmal mit dem gesetzten Hacken in TrueCrypt und einmal ohne.

Macht bei mir keinen Unterschied. Dropbox synchronisiert wohl nur die geänderten Teile.

Aber egal, Karl.

Hauptsache es funktioniert und es werden nicht immer die ganzen 2 GB hochgeladen.

Gruß
Robin

Kommentar am 10. Juli 2011 um 11:24 geschrieben.

HJE sagt

Hallo,

es werden dann 2 GB hochgeladen, wenn man mit zwei verschiedenen Rechnern drauf zugreift.

CIAO

Kommentar am 10. Juli 2011 um 13:41 geschrieben.

J. Bej sagt

Habe einmal eine Frage: Mit welchen Tool wurden die Screenshots auf dieser Seite erstellt? Das interessiert mich besonders in Hinblick auf den roten Pfeil, der in einem Screenshot zu sehen ist. Wurde der anschliessend mit dem Screenshot-Tool eingefügt, oder wurde eine andere Software verwendet? Wenn ja, welche?

Besser spät als nie fragen, oder?

Jo

(Bin auf diese Seite gestossen, weil ich mir gerade einen Truecrypt-Container für Dropbox erstelle.)

Kommentar am 8. August 2011 um 10:13 geschrieben.

Martin sagt

Klingt nach einer guten Lösung TrueCrypt mit der Dropbox zu nutzen … Danke, werde ich gleich mal ausprobieren!

LG,
Martin

Kommentar am 27. September 2011 um 09:57 geschrieben.

chorn sagt

Daten im Truecryptcontainer geändert, Dateigröße bleibt ja gleich, Datum der letzten Änderung bleibt gleich. So hat das über Monate hinweg funktioniert. Immer vom Stick -> in die Dropbox synchronisiert.

Jetzt habe ich wieder was geändert, aber Dropbox synchronisiert nicht. Habe dann Dropbox neu installiert, den Container in den Dropboxordner geschoben – und er synct in die falsceh Richtung, aus der Box in den Container. Klar, Dateigröße gleich, Datum in der Dropbox ist neuer, also aus der Dropbox ziehen, aktuellste Version und so.

Ist aber in meinem Fall falsch. Aber wie ging das denn vorher? Müsste Dropbox nicht immer aus der Box synchen? Denn alle Änderungen am Container liegen ja nach Änderungsdatum in der Vergangenheit. Dropbox sieht die Änderung -> Datei auf dem Server ist neuer -> Datei von Server nach lokal synchen. Wäre ja grundsätzlich falsch.

Kommentar am 10. November 2011 um 17:53 geschrieben.

jw sagt

Ich habe das ganze bei mir jetzt mal installiert, aber ich habe das Problem, dass Dropbox den Container immer nur dann synchronisiert, nachdem ich den Container unmounted habe.

GEht das auch anders?
Zweite Frage, anders als bei Caschy kann ich bei Dropbox nicht sehen, welche Dateien im COntainer geändert wurden, es zeigt mir immer nur an, dass die Datei meines Truecrypt-Containers geändert wurde.

Kommentar am 12. November 2011 um 12:30 geschrieben.

Thomas Schewe ( @thosch66) sagt

@jw

Du hast in beiden Punkten etwas nicht gelesen bzw. falsch verstanden.

1. Im Posting steht deutlich geschrieben, dass der Container erst dann gesynct wird, wenn man den den Container unmouted (“Natürlich sollte man beachten, dass die Änderungen am Container erst vorgenommen werden, wenn dieser via TrueCrypt ausgehangen wird.”).

2. Es gibt _keine_ Möglichkeit, dass man die innerhalb des Containers geänderten Dateien in der Dropbox angezeigt bekommt. Das würde auch dem Sinn von Truecrypt widersprechen, dass der Inhalt des Inhalt des Containers _geheim_ ist.

Es wird im Posting nur beschrieben, dass Dropbox nicht den gesamten Container, sondern nur Teile des Containers synct (nämlich die geänderten Bytes).

Der Screenshot zeigt auch nur, dass bei den verschiedenen Versionen der 10MB-Container-Datei nur kleine Teile gesynct wurde. mehr nicht.

Kommentar am 12. November 2011 um 18:16 geschrieben.

jw sagt

@thomas

danke für die Antwort. Ich hab das mittlerweile auch bemerkt und verstehe jetzt auch deinen Blogeintrag, warum du von Truecrypt und Dropbox abrätst.

Da ich Dropbox auf zwei verschiedenen Rechnern benutze, werde ich wohl genau darauf achten müssen, dass der Container voll gesynct ist, bevor ich den Container auf einem anderen Computer mounte.

du empfiehlst als Alternative ja EncFS, sehe ich das richtig, dass wenn ich EncFS nutzen würde, meine Dateien zwar vor “neugierigen Augen” geschützt würden, aber Dropbox Zugriff auf die Dateien hätte.

(Disclaim: Ich bin eigentlich kein Anhänger der großen Verschwörungstheorie, aber es gibt da ein paar Dateien, bei denen ich mich verpflichtet habe, wenn ich sie auf laptop, usbstick oder in der cloud lege, sie via truecrypt zu verschlüsseln.)

Kommentar am 12. November 2011 um 18:35 geschrieben.

Thomas Schewe ( @thosch66) sagt

@jw

Anders als bei Truecryt, wo es nur einem großen Container gibt und man von außen nicht erkennen kann, ob und wie viel Daten darin stecken, kann man bei EncFS einzelne Dateien sehen, aber Dateiname und Dateiinhalt sind verschlüsselt (und damit natürlich auch für Dropbox nicht einsehbar). Man kann aber sehr wohl sehen,
- wie viele Dateien es sind,
- wie die interne Ornderstruktur aussieht,
- wie groß die Dateien sind und
- wann sie zuletzt geändert wurden.

Ob einen das stört, muss man selber wissen. Der Aussagewert des Dateinamen “SwPqJDEE0WgNqRrd-WfS3RVWyizTg5ryGE,E9G8zJ,mJh5C6fuwmoDT7lAmf3iifx,B” oder des Verzeichnisnamens “hjhSHy4XLIHAEScrPod1PHyzrBW1j2gPlJOp3gh1nHUTj1″ ist IMHO aber wohl sehr eingeschränkt. Die Dateiinhalte selbst sind – wie schon geschrieben – verschlüsselt.

Wenn man eine ausgeprägte Paranoia hat, kann man ja die entsprechenden Verzeichnisse mit zusätzlichen Dummydatei befüllen und diese regelmäßig ändern, um für den Beobachter ein gewisses “Rauschen” zu erzeugen.

Truecrypt bietet hier weniger Einblick, aber in der Dropbox überwiegen IMHO die Nachteile.

Kommentar am 12. November 2011 um 19:41 geschrieben.

Bill Iffmann sagt

In der Dropbox-History wird der Truecryptcontainer auch als geändert angezeit, wenn sein Inhalt nicht verändert wurde.
Z.B. habe ich ihn gemounted, einen CMD-Link darin aufgerufen, auf der Kommandozeile ein Script ausgeführt, was eine Datei aus dem Container öffnet, diese nicht verändert und alles wieder geschlossen und ungemounted. Es wurden zwar keine Änderungen hochgeladen – das Tooltip des DB-Trayicons hat nur eine Datei als indiziert angzeigt – aber in der History auf der DB-Webseite ist der TC-Container als geändert aufgeführt.

Kommentar am 30. Dezember 2011 um 17:06 geschrieben.

Thomas Schewe ( @thosch66) sagt

@Bill:

Kann es sein, dass das im TrueCrypt-Container eingesetzte Dateisystem das Datum des letzten Zugriffs auf die Datei (atime) in die Meta-Daten der Datei speichert und damit doch den Inhalt des Containers verändert? Das ist z.B. bei NTFS (Windows) und ext3/4 (Linux) der Fall.

atime: http://de.wikipedia.org/wiki/A.....28atime.29

Kommentar am 30. Dezember 2011 um 23:07 geschrieben.