[過去ﾛｸﾞ] ファイルシステム総合スレ その20 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
842(2): login:Penguin [] 2024/10/10(木) 23:29:15.63 ID:xeeQIOkG(1/3) AAS
>>840
たぶん「まともなアプリ」は
(1) 上書きせずに同期書き込みで別ファイル作成(Create, Write, Close and Sync)、
(2) 上書き前のファイルを削除、
(3) (1)で作成したファイルをリネーム
する(つまり手間をかける)って話かと。
まともじゃない駄目アプリは (1)-(3) を実行せずに上書き (Truncate and Write)
ですましちゃうから CoW じゃないと処理途中で停電した場合にデータが吹っ飛ぶ
って事じゃないかな。
rename するとファイルの xattr 属性が吹っ飛ぶ/リストアが面倒なので
「まともなアプリ」でも実際には (2),(3) は実行せず、
(2a) オリジナルファイルを上書き (Truncate and Write) だな。
途中で停電になった場合は次回アプリ起動時に修復するかをユーザに問い合わせる。
例えば Linux の vi とか Windows の MS-Word とか起動時に復旧するかが表示される。
843: login:Penguin [] 2024/10/10(木) 23:42:22.27 ID:xeeQIOkG(2/3) AAS
駄目アプリの Truncate and Write の途中で停電になったら
例え CoW であってもファイルの途中までの書き出し状態で復旧するか
上書きする前に戻されるかだけでしかない。
アプリレベルで意味のあるオートセーブデータとか
アプリレベルで意味のあるアンドゥログがあって初めて停電対策になるのであって
アプリより低層のファイルシステムでは打てる策ではどうあがいても
「効果を発するのは限定的」ですね。
844: login:Penguin [] 2024/10/10(木) 23:52:24.30 ID:xeeQIOkG(3/3) AAS
>>842
× リストアが面倒なので
○ ハードリンクの復元が超面倒/思いつかないので
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.042s