アカウント名:
パスワード:
rename(2)がPOSIX仕様に準拠していないので、Windows環境ではファイルをアトミックに交換することができない。当然、Windows環境に引きずられたXamarinでもファイルをアトミックに交換する方法は提供されていないのであろう。こんな環境でまともなプログラムが書けるとは思えないのだが、多数のWindowアプリがゴミなのも当然である。
Linuxの場合(もちろんLinuxに限らず常識的なOSは全部この動作)
rename() はファイルの名前を変更し、必要ならばディレクトリ間の移動を行なう。 そのファイルに対する (link(2) を使用して作られた) 他のハードリンク (hard link) には影響はない。 オープン済の oldpath に対するファイルディスクリプターにも影響はない。newpath が既に存在する場合、それは不可分操作で (atomically) 置き換えられる (ただし、いくつかの条件がある; 以下の「エラー」のセクションを参照)。 そのため、 newpath にアクセスしようとしている他のプロセスがファイルを見失うことはない (訳註: 常にアクセス可能である)。
Windowsの場合
エラーが発生した場合、関数は0以外の値を返し、 errno を次の値のいずれかに設定します。EACCES newname によって指定されたファイルまたはディレクトリが既に存在するか、(無効なパスのため) 作成できない、または oldname がディレクトリであり、newname によって異なるパスが指定されています。
そうゆう場合はReplaceFile系のWin32APIを使うはず.netだとFile.Replace
おじいちゃんは新しいAPIのことは知らないからしょうがないよ。
Windows XPの頃、APIよりコマンドプロンプト経由でのdel命令の方が安定して正確な動作だった経験が未だにファイルをつかんで制御させてくれない時あるよね
かつては Transactional NTFS なるものでアトミック性も含めて保証されていたんですけどね
8から非推奨になったけど、一応10でも使える。
インストーラとか作るの楽だったんだけど、msi作るのが気楽になったから、もう不要なのか。もっとASP.NETが普及してたら、商用ソフトの課金なんかもローカルと複数のサーバー間の同期も単一のトランザクションに出来たのにねぇ。
Vista 出る前のプレビューだと、コマンドラインでトランザクション作って、その上でネットの怪しいソフトインストールして試して、気にいらなくなったらロールバックすれば綺麗さっぱりみたいな事が気軽に出来て良かったんだけどなぁ。Vistaの正式リリース時はコマンドラインからトランザクション作ったりする機能消されたり、出た直後から不遇だった。
http://research.microsoft.com/pubs/64525/tr-2006-45.pdf [microsoft.com]2.2章読んでみそ
なるほどこういうことですね
「Windows環境に引きずられた」って言うけどXamarinはMonoが出発点でしかもモバイル先行だったしでwindowsあんま関係なくね?
Xamarin.Formの開発者がWindowsに引きずられたんだろうて話では。
風説の流布
renameだけがクソみたいな指摘は止めろ。他はまともであるかのように勘違いする奴が出て迷惑だ。だいたいWindowsに限らず、DOS時代からMicrosoftのOSは、ファイル操作全般がゴミクズなのは常識。rename以前に置き換え自体が満足にできないクソ仕様なので、たかが使用中のファイルをアップデートする如きでリブート必須。それすらリブート中にアップデートなどという意味不明な仕様なので、Windows 10のように「アップデート後に再起動ループ」などいう無間地獄に容易く陥る。
すなわち
設定情報を保存したプロパティをシリアライズしてファイルに書き出すロジックで、「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームするコードが書かれているという。そ
「.tmp」に書いて、元を「.org」に変えて、「.tmp」を出力先のファイル名に変えて、「.org」を削除する。これくらいやって、やっとある程度安心する。
original1.「.tmp」に書いて original new.tmp2.元を「.org」に変えて original.org new.tmp3.「.tmp」を出力先のファイル名に変えて original.org original4.「.org」を削除する。 original
... 2の段階で落ちたらなくなるじゃん。全然安心出来んのだが。
originalが無い場合はoriginal.orgが居るかチェックでリカバリー処理を実施だね。#3978951 [srad.jp]と同じ。
アトミック性がないところでは悪くない方式だと思いますが……昔、ネットワークドライブ上でExcelのファイルを上書き保存しようとしてできなかったことがあります。クオータに引っかかっていたのですが、空き容量はもうちょっとあるはずなのに、と思ってよく見ると
>「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームすするコードが書かれているという。
この動作をしていて、空き容量不足でテンポラリファイルの作成に失敗しているようでした。これなら書き込みの途中で失敗しても元ファイルを破壊せずに済みますからね。
# 某ソフトは何も考えずに上書きするっぽくて、# 保存中にスリープボタンを押してしまい、復帰後にもう1回保存すればいいかと思って# 復帰させたらエラーで再起動がかかってしまい、結果としてファイルを壊したことがあるAC
はい、嘘。
Linuxのrenameがアトミックである保証なんてない。フアイルシテム依存なので、標準のvfat実装なら当然アトミックではないし、ext4でもマウントオプション依存。
ファイル操作についてファイルシステム実装ではなく、OS単位で話をする奴は間違いなく何もわかっていない。
それはファイル操作が競合してデータ飛んだりしないだけで、実際にrenameがアトミックであるかどうかは別物。LinuxならSDカード書き込み中に抜いても壊れないとでも思ってんの?
なんでシステム上で保証されることと、SDカード抜いて壊れるってことを同列に語ってるんだよ。お前の理解レベルはマニュアル読んでこいとかそれ以前の問題だ。
SDカード抜くのが簡単にrename操作を中断させられる実例として挙げたんだよ。アトミックとスレッドセーフ区別できてるか?
なにを主張したいのか飛躍しすぎでさっぱりわからん。ユーザーランドからのアクセスに対してアトミックであることをOSが保証しているってことが理解できないの?
SD書き込み中に地震が来て津波に飲まれることも考えておかないといけませんね
アトミックといいますが、どんな高度なシステムであろうと、ある一つのパス名で表現されるデータが一つだけという条件下で切り替えを行うとき、「処理を中断されては困る時間」を真の0秒にはできず、大変短いけれども「魔の時間」が残ってしまうのでは?
CPUがクロックで分断された離散的な時間で動いてるので、連続な時間の真の0秒なんて考えを導入するにが間違い。そんなこと言ったらアトミックって言葉がなににも当てはめられないでしょ。例えばLinuxがサポートする全てのCPUはアドレスの書き換えをアトミックに行うことができる。そこから排他制御だとかいろんなことをカーネルレベルで担保できる。
ハードウェアは物理的実体である以上、実数の時間で動いている。これを微細に検証していくと、本当に危険な時間帯は0だろうか?あなたの言う通り、アトミックという言葉は幻想であり、じつは当てはめられる条件には制限があるのでは?
別ACの茶々ですが、ストレージ等が最適化と称して何かしてたら無駄になるのはあると思うな。renameならほばほぼ大丈夫だと思うけど。
VFSが頑張っても下層のレイヤーがダメならあっさり壊れるのは、過去ストーリー [hardware.srad.jp]でも自明だし。
いま物理現象の話してるんじゃないのわかるよね? ハードウェアが保証する動作について話してるね。じゃぁ、あなたはCPUに1+1を計算させたとき、2ではない結果が返る可能性を考慮してコーディングするわけ?
じつは当てはめられる条件には制限があるのでは?
「あるのでは?」じゃねーよ。お前の妄想なんて知るか。あるなら教えてくれ。
2ではない結果が返る可能性を考慮して
High Availability の世界だとあり得る話 (今回はそこまででもないのですが)。
どんな機械も最終的には物理的な存在の状態変化なのです。一つの状態から別の状態への変化には、必ず「中間の状態」があり、言葉を濁さず書けば、アトミックなものではないということです。CPUに計算させたとき、1+1の結果が返ってこず、エラーとなることはあり得ます。本当に信頼性が欲しいのなら、エラー発生も考慮してプログラミングする必要があります。今回の場合であれば、ファイルを削除して、その後リネームするまでの間に障害が起きたことを考慮し、起動時にそれを検証、修復するか、もっと大げさにやるなら情報を保存する箇所を複数に冗長化するなどの対策が必要でした。そこまでやって守らなくてはならない情報なのか、という問題はありますが。
ライブラリ関数でもましてやシステムコールでもない1+1がCPUから返ってこなかったら、それは既にクラッシュしてて救いようがない状態でしょ。そんな状態でエラー処理が動くはずがないし、そもそもエラー処理のためにどんだけCPUが計算してると思ってるの?宇宙線でビット反転とか、安全のために3系統で多数決とかはあるにしてもだ、それは「アトミックなものではない」とか「中間の状態」なんてこととは関係ない。君の言ってることは0と1で動いてるコンピュータが0.5的なものを返すかもしれないって話だよね?それ壊れてるよ。
なんとかして「仕方なかったんだ」ということにしたい勢力がいるんだろうなあ
なんとかして「発注のせいなんだ」ということにしたい勢力がいるんだろうなあ
Windows環境に引きずられたXamarinの不具合を受けたんだから関係あるだろ。
オフトピックモデで
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
Windowsのrename()関数を書いたやつは頭がおかしい (スコア:-1, オフトピック)
rename(2)がPOSIX仕様に準拠していないので、Windows環境ではファイルをアトミックに交換することができない。当然、Windows環境に引きずられたXamarinでもファイルをアトミックに交換する方法は提供されていないのであろう。
こんな環境でまともなプログラムが書けるとは思えないのだが、多数のWindowアプリがゴミなのも当然である。
Linuxの場合(もちろんLinuxに限らず常識的なOSは全部この動作)
Windowsの場合
Re:Windowsのrename()関数を書いたやつは頭がおかしい (スコア:1)
そうゆう場合はReplaceFile系のWin32APIを使うはず
.netだとFile.Replace
Re: (スコア:0)
おじいちゃんは新しいAPIのことは知らないからしょうがないよ。
Re: (スコア:0)
Windows XPの頃、APIよりコマンドプロンプト経由でのdel命令の方が安定して正確な動作だった経験が
未だにファイルをつかんで制御させてくれない時あるよね
Re: (スコア:0)
きっとアトミックに違いないと信じて行っている呪術プログラミングを世界中でやってるだけなんだよねこれが。
Re: (スコア:0)
かつては Transactional NTFS なるものでアトミック性も含めて保証されていたんですけどね
Re: (スコア:0)
8から非推奨になったけど、一応10でも使える。
インストーラとか作るの楽だったんだけど、msi作るのが気楽になったから、もう不要なのか。
もっとASP.NETが普及してたら、商用ソフトの課金なんかもローカルと複数のサーバー間の同期も単一のトランザクションに出来たのにねぇ。
Vista 出る前のプレビューだと、コマンドラインでトランザクション作って、その上でネットの怪しいソフトインストールして試して、気にいらなくなったらロールバックすれば綺麗さっぱりみたいな事が気軽に出来て良かったんだけどなぁ。
Vistaの正式リリース時はコマンドラインからトランザクション作ったりする機能消されたり、出た直後から不遇だった。
Re: (スコア:0)
Re: (スコア:0)
http://research.microsoft.com/pubs/64525/tr-2006-45.pdf [microsoft.com]
2.2章読んでみそ
Re: (スコア:0)
でもReplaceFileの仕様に1行足すだけのことは絶対にしないので
未来のWindowsで突然アトミックでなくなる可能性がないとは言えないし、そうなっても、ドキュメント読んでないお前が悪いってことになるの
Xamarinで重要なアプリを書いたやつは頭がおかしい (スコア:0)
なるほど
こういうことですね
Re: (スコア:0)
「Windows環境に引きずられた」って言うけどXamarinはMonoが出発点でしかもモバイル先行だったしでwindowsあんま関係なくね?
Re: (スコア:0)
Xamarin.Formの開発者がWindowsに引きずられたんだろうて話では。
Re: (スコア:0)
風説の流布
Re: (スコア:0)
renameだけがクソみたいな指摘は止めろ。他はまともであるかのように勘違いする奴が出て迷惑だ。
だいたいWindowsに限らず、DOS時代からMicrosoftのOSは、ファイル操作全般がゴミクズなのは常識。
rename以前に置き換え自体が満足にできないクソ仕様なので、たかが使用中のファイルをアップデートする如きでリブート必須。
それすらリブート中にアップデートなどという意味不明な仕様なので、Windows 10のように「アップデート後に再起動ループ」などいう無間地獄に容易く陥る。
すなわち
設定情報を保存したプロパティをシリアライズしてファイルに書き出すロジックで、「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームするコードが書かれているという。そ
Re: (スコア:0)
「.tmp」に書いて、元を「.org」に変えて、「.tmp」を出力先のファイル名に変えて、「.org」を削除する。
これくらいやって、やっとある程度安心する。
Re: (スコア:0)
original
1.「.tmp」に書いて
original
new.tmp
2.元を「.org」に変えて
original.org
new.tmp
3.「.tmp」を出力先のファイル名に変えて
original.org
original
4.「.org」を削除する。
original
... 2の段階で落ちたらなくなるじゃん。全然安心出来んのだが。
Re: (スコア:0)
originalが無い場合はoriginal.orgが居るかチェックでリカバリー処理を実施だね。
#3978951 [srad.jp]と同じ。
Re: (スコア:0)
アトミック性がないところでは悪くない方式だと思いますが……
昔、ネットワークドライブ上でExcelのファイルを上書き保存しようとしてできなかったことがあります。
クオータに引っかかっていたのですが、空き容量はもうちょっとあるはずなのに、と思ってよく見ると
>「.tmp」に書き出したのちに、元のファイルを削除してから、「.tmp」を元のファイル名にリネームすするコードが書かれているという。
この動作をしていて、空き容量不足でテンポラリファイルの作成に失敗しているようでした。
これなら書き込みの途中で失敗しても元ファイルを破壊せずに済みますからね。
# 某ソフトは何も考えずに上書きするっぽくて、
# 保存中にスリープボタンを押してしまい、復帰後にもう1回保存すればいいかと思って
# 復帰させたらエラーで再起動がかかってしまい、結果としてファイルを壊したことがあるAC
Re: (スコア:0)
はい、嘘。
Linuxのrenameがアトミックである保証なんてない。
フアイルシテム依存なので、標準のvfat実装なら当然アトミックではないし、ext4でもマウントオプション依存。
ファイル操作についてファイルシステム実装ではなく、OS単位で話をする奴は間違いなく何もわかっていない。
Re: (スコア:0)
Re: (スコア:0)
それはファイル操作が競合してデータ飛んだりしないだけで、実際にrenameがアトミックであるかどうかは別物。
LinuxならSDカード書き込み中に抜いても壊れないとでも思ってんの?
Re: (スコア:0)
なんでシステム上で保証されることと、SDカード抜いて壊れるってことを同列に語ってるんだよ。
お前の理解レベルはマニュアル読んでこいとかそれ以前の問題だ。
Re: (スコア:0)
SDカード抜くのが簡単にrename操作を中断させられる実例として挙げたんだよ。
アトミックとスレッドセーフ区別できてるか?
Re: (スコア:0)
なにを主張したいのか飛躍しすぎでさっぱりわからん。
ユーザーランドからのアクセスに対してアトミックであることをOSが保証しているってことが理解できないの?
Re: (スコア:0)
SD書き込み中に地震が来て津波に飲まれることも考えておかないといけませんね
Re: (スコア:0)
アトミックといいますが、どんな高度なシステムであろうと、ある一つのパス名で表現されるデータが一つだけという条件下で切り替えを行うとき、「処理を中断されては困る時間」を真の0秒にはできず、大変短いけれども「魔の時間」が残ってしまうのでは?
Re: (スコア:0)
CPUがクロックで分断された離散的な時間で動いてるので、連続な時間の真の0秒なんて考えを導入するにが間違い。そんなこと言ったらアトミックって言葉がなににも当てはめられないでしょ。例えばLinuxがサポートする全てのCPUはアドレスの書き換えをアトミックに行うことができる。そこから排他制御だとかいろんなことをカーネルレベルで担保できる。
Re: (スコア:0)
ハードウェアは物理的実体である以上、実数の時間で動いている。これを微細に検証していくと、本当に危険な時間帯は0だろうか?あなたの言う通り、アトミックという言葉は幻想であり、じつは当てはめられる条件には制限があるのでは?
Re: (スコア:0)
別ACの茶々ですが、ストレージ等が最適化と称して何かしてたら無駄になるのはあると思うな。
renameならほばほぼ大丈夫だと思うけど。
VFSが頑張っても下層のレイヤーがダメならあっさり壊れるのは、過去ストーリー [hardware.srad.jp]でも自明だし。
Re: (スコア:0)
いま物理現象の話してるんじゃないのわかるよね? ハードウェアが保証する動作について話してるね。じゃぁ、あなたはCPUに1+1を計算させたとき、2ではない結果が返る可能性を考慮してコーディングするわけ?
じつは当てはめられる条件には制限があるのでは?
「あるのでは?」じゃねーよ。お前の妄想なんて知るか。あるなら教えてくれ。
Re:Windowsのrename()関数を書いたやつは頭がおかしい (スコア:1)
High Availability の世界だとあり得る話 (今回はそこまででもないのですが)。
Re: (スコア:0)
どんな機械も最終的には物理的な存在の状態変化なのです。一つの状態から別の状態への変化には、必ず「中間の状態」があり、言葉を濁さず書けば、アトミックなものではないということです。
CPUに計算させたとき、1+1の結果が返ってこず、エラーとなることはあり得ます。本当に信頼性が欲しいのなら、エラー発生も考慮してプログラミングする必要があります。
今回の場合であれば、ファイルを削除して、その後リネームするまでの間に障害が起きたことを考慮し、起動時にそれを検証、修復するか、もっと大げさにやるなら情報を保存する箇所を複数に冗長化するなどの対策が必要でした。そこまでやって守らなくてはならない情報なのか、という問題はありますが。
Re: (スコア:0)
Re: (スコア:0)
ライブラリ関数でもましてやシステムコールでもない1+1がCPUから返ってこなかったら、それは既にクラッシュしてて救いようがない状態でしょ。そんな状態でエラー処理が動くはずがないし、そもそもエラー処理のためにどんだけCPUが計算してると思ってるの?
宇宙線でビット反転とか、安全のために3系統で多数決とかはあるにしてもだ、それは「アトミックなものではない」とか「中間の状態」なんてこととは関係ない。君の言ってることは0と1で動いてるコンピュータが0.5的なものを返すかもしれないって話だよね?それ壊れてるよ。
Re: (スコア:0)
なんとかして「仕方なかったんだ」ということにしたい勢力がいるんだろうなあ
Re: (スコア:0)
なんとかして「発注のせいなんだ」ということにしたい勢力がいるんだろうなあ
Re: (スコア:0)
Windows環境に引きずられたXamarinの不具合を受けたんだから関係あるだろ。
Re: (スコア:0)
オフトピックモデで