アカウント名:
パスワード:
>TrueCryptのボリュームファイルをDropBoxに置けばOK、と。
ボリュームの一部（たとえば数KB）が書き換わっても、ボリューム全体送信しちゃうんじゃdropboxの負担よりユーザーの方がやきもきしそう。
DropBox & TrueCrypt を実際にやっておりますが、どうもアップロード速度から判断する限りは差分のみ送っているようなので数GBもあるTrueCryptファイルをストレス無く共有できてます。
ただ、同期のタイミングによって、昨晩自宅で編集したものを翌朝会社で編集しているとかで、コンフリクトが発生することは時折起こります。ですので最低限、２倍の空きの確保が必要なのは何ともしがたいですね。
> DropBox & TrueCrypt を実際にやっておりますが、> どうもアップロード速度から判断する限りは差分のみ送っているようなので
差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。
そして、誰が差分を作るかですが、クライアントとサーバーのどちらかになりますが、サーバーだとしたら、現在のファイルはクライアントにアップロードしなければ、差分を作ることが出来ません。もし、クライアントだとしたら、元ファイルが必要です。元ファイルがクライアントにあるのでしょうか？
確かに。一応クライアント側にキャッシュフォルダはあるようですが、.svn みたいにオリジナルを保持しているようには見えませんね。
私が想像したのは、例えば大きいファイルを分割してクライアント側でブロック別にハッシュ値を計算するなどすれば、差分を取るのに必ずしもsrc-dest両方の全バイトが必要ではないですよね。もともとDropBoxは差分を記憶するVC機能も有しているので、こういった仕組みを用いている可能性はあるか、といったところです。が、今回の騒動を見るとあんまり凝ったことはしてない可能性の方が高いかなとも思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
暗号化されてないならすれば良いじゃない (スコア:1)
DropBoxのシステムにどれぐらい余分な負荷をかけちゃうのか知らないけど。
Re: (スコア:0)
>TrueCryptのボリュームファイルをDropBoxに置けばOK、と。
ボリュームの一部（たとえば数KB）が書き換わっても、ボリューム全体送信しちゃうんじゃ
dropboxの負担よりユーザーの方がやきもきしそう。
Re: (スコア:1)
Re: (スコア:2)
DropBox & TrueCrypt を実際にやっておりますが、
どうもアップロード速度から判断する限りは差分のみ送っているようなので
数GBもあるTrueCryptファイルをストレス無く共有できてます。
ただ、同期のタイミングによって、昨晩自宅で編集したものを
翌朝会社で編集しているとかで、コンフリクトが発生することは時折起こります。
ですので最低限、２倍の空きの確保が必要なのは何ともしがたいですね。
Re: (スコア:1)
> DropBox & TrueCrypt を実際にやっておりますが、
> どうもアップロード速度から判断する限りは差分のみ送っているようなので
差分を作るには、比較対象の元ファイルと現在のファイルの二つが必要です。
そして、誰が差分を作るかですが、クライアントとサーバーのどちらかになりますが、
サーバーだとしたら、現在のファイルはクライアントにアップロードしなければ、
差分を作ることが出来ません。
もし、クライアントだとしたら、元ファイルが必要です。元ファイルがクライアントにあるのでしょうか？
Re:暗号化されてないならすれば良いじゃない (スコア:3, すばらしい洞察)
確かに。
一応クライアント側にキャッシュフォルダはあるようですが、.svn みたいにオリジナルを保持しているようには見えませんね。
私が想像したのは、
例えば大きいファイルを分割してクライアント側でブロック別にハッシュ値を計算するなどすれば、
差分を取るのに必ずしもsrc-dest両方の全バイトが必要ではないですよね。
もともとDropBoxは差分を記憶するVC機能も有しているので、こういった仕組みを用いている可能性はあるか、
といったところです。
が、今回の騒動を見るとあんまり凝ったことはしてない可能性の方が高いかなとも思います。