全言語で気をつけるべき、ファイル書き込み時のお作法 - Qiita

言いたいこと 重要なファイルを書くときは、予期しないOSシャットダウンなどを考慮した書き方にする必要があるというお話。 お作法を知らないと、中途半端なファイルや空ファイルが生成され、システム起動時や連携システムで致命的なことになる。 例としてC言語/Java/Python/JavaScript(node.js)を挙げるが、ほぼすべての言語で対策する必要あり。 背景 本番運用されているソフトウェアが起動しなくなるという致命的な不具合が発生した。 ログやコンフィグファイルを収集・解析したところ、コンフィグファイルがぶっ壊れていた。 コンフィグファイルは起動時に読まれるが、必要に応じて書き込まれることもある。 コードを追っていくと、書き込み処理中に強制終了したりすると、中途半端に書かれる可能性があることに気づく。 使い終わると電源がぶち切りされる運用をされており、奇跡的にタイミングが重なったのか

[efcl]

Linuxのfsyncとfdatasyncについて

[lorenz_sys]

「ほぼすべての言語で対策する必要あり」は失礼だけどちょっと疑問。現代のシステム開発は予期しないOSシャットダウン(特に電源断)などいちいち前提にしないと思うけどな？DBは電源断時にどうする？切りがないから。

[moxtaka]

"ソフトでなんとかしろという無茶振りに対して、「fsync を定期的に呼ぶ」という小手先の対応でお茶を濁し、自分の在職中に顧客からクレームが来ないことを祈る、というのが組み込みLinuxのアンチパターンです。"

[W53SA]

「使い終わると電源がぶち切りされる運用」組み込み系なのか、はたまた修羅場なのか…

[tmatsuu]

flushだけではダメ、別途fsync。golangだとos.File.Sync()だろうか。

[otihateten3510]

やっぱファイル怖いわ　どうテストすればいいだろう

[daichirata]

rubyの場合はio.sync=trueでバッファリングしないっていうのがお作法だったりするよね

[buhoho]

"使い終わると電源がぶち切りされる運用"ええー！と思ったけどIoT機器ならありそう

[y_r]

write しても OS までいかない -> flush しても永続層までいかない -> fsync せよ / flose じゃだめ / いつ電源が切られるかは開発者には予期できない / ↓ DB は DB 内部で対策してる。例えば SQLite https://www.sqlite.org/lockingv3.html

[k2wanko]

Cloudに慣れきってるとローカルに書き出したら負けみたいな感じになってついつい忘れがち

[shozzy]

“使い終わると電源がぶち切りされる運用”　怖い... ／rubyだとIO#fsyncか。https://docs.ruby-lang.org/ja/latest/method/IO/i/fsync.html

[vanbraam]

fsync,fdatasync;どういうアプリかわからないけど,そもそも動作中にconfigを書き換える造りや,電源ぶち切りの運用がイケてないのでは?何にせよ書き出し処理の安全化は必要だが

[perl-o-pal]

電源を切る前にはSTOPボタンを連打して、ヘッドをシッピングゾーンに退避させないと。

[yarumato]

“C言語/Java/Pythonの例。Windows7やCentOS6で確認。正規シャットダウンでは起きないが予期しないOSシャットダウンで中途半端なファイル生成を防ぐためダーティバッファの書き出し完了（30秒かかることもある）を待つ方法”

[mas-higa]

Ruby だと IO#sync= に true を渡してやると、そのファイルが同期モードになるっぽい。

[zetamatta]

これ、fclose のエラーをちゃんとチェックすればよい話じゃないですかね？（実験してないけど）