[過去ﾛｸﾞ]
ファイルシステム総合スレ その20 (1002ﾚｽ)
ファイルシステム総合スレ その20 http://mao.5ch.net/test/read.cgi/linux/1722312892/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
842: login:Penguin [] 2024/10/10(木) 23:29:15.63 ID:xeeQIOkG >>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 とか起動時に復旧するかが表示される。 http://mao.5ch.net/test/read.cgi/linux/1722312892/842
843: login:Penguin [] 2024/10/10(木) 23:42:22.27 ID:xeeQIOkG 駄目アプリの Truncate and Write の途中で停電になったら 例え CoW であってもファイルの途中までの書き出し状態で復旧するか 上書きする前に戻されるかだけでしかない。 アプリレベルで意味のあるオートセーブデータとか アプリレベルで意味のあるアンドゥログがあって初めて停電対策になるのであって アプリより低層のファイルシステムでは打てる策ではどうあがいても 「効果を発するのは限定的」ですね。 http://mao.5ch.net/test/read.cgi/linux/1722312892/843
844: login:Penguin [] 2024/10/10(木) 23:52:24.30 ID:xeeQIOkG >>842 × リストアが面倒なので ○ ハードリンクの復元が超面倒/思いつかないので http://mao.5ch.net/test/read.cgi/linux/1722312892/844
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.045s