wallet.datの自動バックアップ
他の多くの人と同じで、wallet.datのバックアップが必要だ。そしてこれはサーバー上にあるため、無人で実行される必要がある。また、このサーバーは宝くじに使用されているため、bitcoindを停止してはならない。
今のところ単にファイルをコピーしており、破損したファイルに耐えられるよう頻繁に行っている。しかしこれは理想的ではない。すべてのトランザクション後にバックアップしたほうがいい（送信のときだけだよね？ 送金の受信時には新しいアドレスは作成されないはずだが）。あるいは新しいアドレスを作成するたびにバックアップしたほうがいい。
そのため、ファイルをコピーする代わりに、db_dumpを使用して内容をダンプし、念のため-rフラグを使用することを考えた。これは機能するだろうか？
理想的な解決策は、以下のいずれかを行うRPC呼び出しだ：
- フラッシュして、新しいRPC呼び出し（どの呼び出しでもよく、ロック解除コマンドである必要はない）が来るまで更新をロックする
- フラッシュしてwallet.datを別のファイルにコピーする
- フラッシュしてjsonrpc経由でダンプする。各鍵が配列内で個別に返されれば、‘lastseen=X’を指定して新しい鍵のみを取得できる
これは実現可能だろうか？ どれが最も適しているだろうか？
topic 873がやや関連している。
別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。
主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。
nelisky、あなたと同じアイデアを投稿し始めていた。
ウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか？ プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？ Boostに何かあるか？
名前は何がよいだろうか？ 例えば：backupwallet <destination>
別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。
主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。
nelisky、あなたと同じアイデアを投稿し始めていた。
そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう？ アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。
サトシ・ナカモトウォレットをロックし、フラッシュし、wallet.datを指定した場所にコピーしてからアンロックするjson-rpcコマンドはどうだろうか？ プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？ Boostに何かあるか？
名前は何がよいだろうか？ 例えば：backupwallet <destination>
名前も実装アプローチも全て素晴らしい。
ファイルコピーについては、boost依存を増やす必要があるだろうか？ 私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう？ http://www.dreamincode.net/code/snippet2306.htmのようなもの（ざっと検索した結果で試していないが、正しそうだ）。
さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか？ まあ、これが適切に動作するにはファイルロックに依存することになるが、Windowsではファイルロックがひどかった記憶がある。あっちでコーディングしたのは随分前だが 😊
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？ Boostに何かあるか？
mmap(2) + memcpy(3) か？ Boost::Iostreamsには既にmapped_file Sourceがある。
サトシ・ナカモト名前は何がよいだろうか？ 例えば：backupwallet <destination>
非常に便利そうだ！
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。
neliskyの投稿（2010年8月26日01:21 UTC）ファイルのコピーについて、なぜBoostへの依存を増やすのか？ コアライブラリは依存関係が少ない方がいい。
JSONやwxWidgetsの依存関係を置き換える多数のものにBoostが必要だ。Boostは良い、ポータブルなもので、避けるべきではない。
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。
neliskyの投稿（2010年8月26日01:21 UTC）ファイルのコピーについて、なぜBoostへの依存を増やすのか？ コアライブラリは依存関係が少ない方がいい。
JSONやwxWidgetsの依存関係を置き換える多数のものにBoostが必要だ。Boostは良い、ポータブルなもので、避けるべきではない。
では、私が言及したスニペットのシンプルな標準fstreamの使用の何が問題なのかな？ シンプルが一番だと思う 😊
しかしboost::filesystemの機能を既に使っているなら、そこからcopy_fileを使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
mmapが何をするか、誤解しているのではないだろうか？ mmap / CreateFileMappingはファイルをヒープメモリーに読み込むのではない：http://en.wikipedia.org/wiki/Mmap
Windowsにmmap(2)があるとは思えない。自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良い。
neliskyの投稿（2010年8月27日01:21 UTC）しかしboost::filesystemの機能を既に使っているなら、そこからcopy_fileを使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。
ありがとう。どこかにあるだろうと思っていた。
すでに十数箇所でboost::filesystemを使っている。新たに追加される依存関係ではない。そうでなければ各OSごとに#ifdefを用意してあらゆる場所でテストしなければならないような、多くのポータブルなものを提供してくれる。
Windowsにmmap(2)があるとは思えない。
Windowsバージョンのmmapは返信したメッセージで言及した：CreateFileMapping
以前のメッセージで、boostからの使い方を述べた：Boost::Iostreamsには既にmapped_file Sourceがある。
すまない、最近非常に忙しくてメッセージを流し読みしているが、それでも追いつけない。
可能な限りWindows API呼び出しは避けたい。通常6〜8個のパラメーターが必要で、正しく動作させるために多くのテストが必要で、簡単なことを行うのに1ページ分のコードが必要になる。
通常iostreamsは避けている。よく制限にぶつかるようだ。90年代にC++ストリーム標準をやや台無しにしてしまった。残念なことに、正しく実装すればストリームは非常に強力で便利なものになり得る。rpc.cppで使っているのは、まだ間違いだったと判明するかもしれない。
結論は、自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良いということだ。
いいね。<destination>を設定オプションとして指定でき、bitcoinの送信（/受信？）のたびにその関数を呼び出す、というのはどうだろう？
いいね。<destination>を設定オプションとして指定でき、bitcoinの送信（/受信？）のたびにその関数を呼び出す、というのはどうだろう？
私は新しいアドレスを作るたび、そしてbtcを送信するときにバックアップを取っている。受信は安全なはずだよね？ また、他のものも集めていて、ウォレットのオフサイトscpバックアップもやっている。つまりプログラムロジックにトリガーを組み込んでいる、ということだ。だが自動バックアップがあると素晴らしい。バックアップファイルの変更を監視して、それをトリガーにオフサイトを実行することができるからだ。
ただ、私が本当に素晴らしいと思うのは、何らかのイベントメカニズムだ 😊