C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[55]: ディレクトリの排他アクセス [1]

(過去ログ 40 を表示中)

[トピック内 142 記事 (21 - 40 表示)]　 << 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 >>

■20142 / inTopicNo.21)

　Re[12]: ディレクトリの排他アクセス

▼■

□投稿者/ れい (598回)-(2008/06/06(Fri) 15:50:45)

お。
お返事が。

■No20137 (すさん) に返信
> ■No20105 (れいさん) に返信
>>つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
>>ディレクトリの排他ロックが可能であってもコード量は変化しません。
>>大変なことにはなりません。
>
> そんなことはありません。エラーの発生状況や頻度が変われば、
> 対処も変えなければなりません。

んー。そうですね。
共有違反の頻度が激しく上がるなら、
根本的に変えなきゃいけない場合もありえると思いますが…

> なら、予想より実際に試してみたほうが早いのでは？

それがですね。
一応やってみてはいるんですが…確かなことが言えないのです。

確かにユーザーフォルダとかをロックすると多少困りはしますが、
エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

乱用しまくると確かに邪魔ですが、ファイルロックの乱用も同様に邪魔です。
それと比べてどのくらい邪魔なのか、どう比較するのかわかりません。

どこまで行儀の悪いプログラムを考慮するべきかというのもよくわからない要素の一つで。
最悪プロセスを殺せばいいわけですが、
それをどの程度重く考えるべきなのかも人や状況によって違います。

条件が複雑で曖昧なので、
普通に考えて全然問題ない、とも言えず、
普通に考えてロックがうざくて使えない、とも言えないなぁと。
微妙な感じです。

OSは結構な頻度でディレクトリを「共有書き込み禁止」で開いてますが、
邪魔になることは普通ありませんよね？
それはアクセスが細切れになってるから邪魔じゃないのか、
邪魔にならないようにシステムが調節してるのか、
そもそもディレクトリロックはそれほど邪魔じゃないのか。

いろいろ試したのですが、自信を持って言えるほど十分に試せませんでした。
#予想としては困らないと思うんですが…。
私が気づいていない致命的欠陥があったり、何か大切なところで勘違いしてたり、
そういうことがありそうなのでここで皆さんの知恵をお借りしたいと。

> そんなことはないと思います。同時実行性が相当損なわれると思います。

排他でアクセスできるようなシステムだと「同時実行性が相当損なわれる」ような状況というのは
どのような状況でしょうか？
まさにそれが、知りたい所です。

引用返信 編集キー/

■20143 / inTopicNo.22)

　Re[13]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (12回)-(2008/06/06(Fri) 16:07:49)

■No20142 (れいさん) に返信
> エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

ん？　そういうモデルじゃロックの意味がないでしょ？

ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
の間書き込み禁止するからロックの意味があるのでは？

こういうモデルだと、相当長い期間ロックされるので、相当困ったことになると
思いますが。

引用返信 編集キー/

■20144 / inTopicNo.23)

　Re[12]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ネタ好き (379回)-(2008/06/06(Fri) 16:10:28)

>エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。

これは正しいと思います。DBでも読み込み可、書き込み禁止のロックは一般的です。

引用返信 編集キー/

■20145 / inTopicNo.24)

　Re[14]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (599回)-(2008/06/06(Fri) 16:36:36)

■No20143 (すさん) に返信
> ■No20142 (れいさん) に返信
>>エントリを列挙してる間書き込み禁止、といった程度では殆ど影響ありません。
>
> ん？　そういうモデルじゃロックの意味がないでしょ？

なぜでしょう？
少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。

> ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
> の間書き込み禁止するからロックの意味があるのでは？

おやや？
それが「ふつう」だと考えるのですか。

ではすさんは「ディレクトリのロック」と聞いたときに、
ディレクトリ内の整合性をとるための機能だと思うわけですね？
NyaRuRuさんが示したTxFで実現されてるような機能を想像しているということですね。

なるほど。

「ロック」とばかり言っていたので誤解を招いたようですが、

■No19998 (れいさん) に返信
> Windowsでファイルを開くとき、共有モードやアクセス権を設定して開きます。
> 共有しないと設定してファイルを開けば、
> 他のプロセスからファイルが削除されたり変更されたりすることがないという前提でプログラムを作れます。
>
> ですが、ディレクトリを扱う場合はこれができません。

上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
「共用アクセス制御」の方のロックを話題にしていました。
.Net的に言うなら、「FileShare」の話です。

一応誤解ないように書いておきますが、
「FileStream.Lock」のようなロックはディレクトリにはありません。
APIにもありませんし、Windows内部にもありません。

ディレクトリのアクセス制御といったときにどんなアクセス制御の話をしてるのかよくわからない、
というのもアクセス制御がない理由の一つかもしれないですねぇ。

引用返信 編集キー/

■20146 / inTopicNo.25)

　Re[15]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (13回)-(2008/06/06(Fri) 17:12:36)

■No20145 (れいさん) に返信
> なぜでしょう？
> 少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。

そんなのに何か価値があります？
エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
するのと、大して違いませんが。。。

>>ふつう、エントリを列挙して、アプリが何か処理して、エントリを書き込みするまで
>>の間書き込み禁止するからロックの意味があるのでは？
>
> おやや？
> それが「ふつう」だと考えるのですか。

おや、違うんですか？

例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
想定したのですが。。。

引用返信 編集キー/

■20148 / inTopicNo.26)

　Re[16]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (600回)-(2008/06/06(Fri) 17:41:20)

■No20146 (すさん) に返信
> ■No20145 (れいさん) に返信
>>なぜでしょう？
>>少なくともエントリの列挙中にエントリが削除されたり追加されたりしなくなる、という意味がありますが。
>
> そんなのに何か価値があります？
> エントリを列挙し終えてロックが外れた瞬間、エントリが削除されたり追加されたり
> するのと、大して違いませんが。。。

No20027あたりで書いてますが、
ファイルシステムを利用する側からみると大していいことはありません。

ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
エントリの属性を適用する際に整合性を維持することもできるとか。

>>それが「ふつう」だと考えるのですか。
> おや、違うんですか？

私には「ふつう」どう考えるのかはわかりませんので、違うかどうかはわかりませんが、
それをすさんが「ふつう」と捉えているというのはちょっと興味深いです。

> 例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
> それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
> 想定したのですが。。。

ふむふむ。
やはりディレクトリ内での整合性の維持、ということですね。
読み直してみるに、シャノンさんもそう捉えていたということかしら。

「ディレクトリのロック」とだけ言うと、
そう捉える人は少なからず居るようですね。
「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。

引用返信 編集キー/

■20150 / inTopicNo.27)

　Re[17]: ディレクトリの排他アクセス

▲▼■

□投稿者/ シャノン (457回)-(2008/06/06(Fri) 18:06:41)

2008/06/06(Fri) 18:08:41 編集(投稿者)

■No20148 (れいさん) に返信

出来ても何が嬉しい訳でもないけれど、そうなっている方が自然だと思う、ってことですかね？

<追記>

> 上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
> 「共用アクセス制御」の方のロックを話題にしていました。
> .Net的に言うなら、「FileShare」の話です。

これはよくわかんなかったです。
FileShare.None を指定すれば、同一プロセスからしか書き込めなくなると思いますが。
（同一プロセスからさえ、別ハンドル経由では書き込めませんけど）。

</追記>

引用返信 編集キー/

■20151 / inTopicNo.28)

　Re[17]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (14回)-(2008/06/06(Fri) 18:17:11)

■No20148 (れいさん) に返信
> ファイルシステムを利用する側からみると大していいことはありません。

それが、れいさんが欲してた「理由」なのでは？

> ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、

抜けはチェックの仕様がないような。
重複のチェックは可能だけど、必要なのは場合によりけりだし。

> エントリの属性を適用する際に整合性を維持することもできるとか。

どういうことでしょう？

> やはりディレクトリ内での整合性の維持、ということですね。
> 読み直してみるに、シャノンさんもそう捉えていたということかしら。
>
> 「ディレクトリのロック」とだけ言うと、
> そう捉える人は少なからず居るようですね。

ロックで、整合性以外に思い浮かぶものがないんですけど。。。

> 「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。

と言われても、共用アクセス制御って知らないですけど。。。
MSDNライブラリで引いても出て来ないし。。。

引用返信 編集キー/

■20158 / inTopicNo.29)

　Re[18]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (601回)-(2008/06/06(Fri) 19:39:25)

■No20150 (シャノンさん) に返信
> 出来ても何が嬉しい訳でもないけれど、そうなっている方が自然だと思う、ってことですかね？

そうです。
私個人的にはかなりうれしいですが。

>>上記のように、ロックはロックでも、「同一プロセスからしか書き込めない」というロックではなく、
>>「共用アクセス制御」の方のロックを話題にしていました。
>>.Net的に言うなら、「FileShare」の話です。
>
> これはよくわかんなかったです。

むむ。
この説明でもダメですか。難しい。

ユーザーが利用できるWindowsのファイルアクセス制御は2種類あります。

一つは、LockFile関数などで設定できる「Byte Range Lock」です。
よくわかりませんが、ロックと言うとこれを指す人も多いのかも知れません。
これは、プロセス毎のロックです。
(duplicateされた)同じハンドルを使ってもプロセスが異なればアクセスできません。
同じプロセスであればハンドルが違ってもアクセスできます。
これは、ストリームの領域を指定してロックしますので、ディレクトリでは定義されません。

もう一つは、「共有モード」と「アクセス権」による制御で、私はこれを話していました。
これはプロセス毎のロックではなく、ハンドル毎のロックです。
(duplicateしたハンドルを使えば)他プロセスからでもファイルを利用できます。
同じプロセスが同じファイルを開こうとしても、ハンドルが作れずアクセスできない場合もありえます。
共有アクセス制御は、ファイルシステムレベルではファイル/ディレクトリの区別なく実装されています。

> FileShare.None を指定すれば、同一プロセスからしか書き込めなくなると思いますが。
> （同一プロセスからさえ、別ハンドル経由では書き込めませんけど）。

FileShare.Noneを指定すると同一ハンドルをからしか利用できないというのが正確です。
ディレクトリをFileShare.Noneで開くと、
たとえ同じプロセスであってもそのハンドル以外では読めなくなります。

ですので、現状ではディレクトリハンドルを排他で開くと、
FindFirstFileやSetCurrentDirectoryなどは共有違反になります。
(パス文字列を引数に取るので、ディレクトリハンドルを指定する方法がない）

このように、Win32ではディレクトリに関する関数は引数にパス文字を取ることが多く、
ハンドルは限定的にしか利用できません。

ディレクトリにもハンドルがあり、一部の関数(ReadDirectoryChangesなど)では
そのハンドルを取るよう作られているのに、
FindFirstFileもSetCurrentDirectoryもハンドルを引数には取れないと言うのが不思議なわけです。
ディレクトリのハンドルを開くときに、CreateFileで普通に共有モードを指定して開けないのが不思議なわけです。

これで伝わったでしょうか？

■No20151 (すさん) に返信
> それが、れいさんが欲してた「理由」なのでは？

いいえ。
それは現状を維持する理由にはなりますが、選択する理由にはなりません。
前にも書いてますが。
他にもっといい方法があるように思えるのに、
敢えてこうなっている、合理的理由が欲しいわけです。

>>ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
>
> 抜けはチェックの仕様がないような。

いいえ。
例えば。
「FileShare.Read」でディレクトリを開いた上でエントリの存在を確認すれば、
ディレクトリハンドルを閉じるまではエントリの存在が保証される、
そんな実装も可能です。

>>エントリの属性を適用する際に整合性を維持することもできるとか。
> どういうことでしょう？

ディレクトリのFileAttributesを設定して次にCreationDateを変更するときとか、
一度に出来ない作業の場合は排他で開けると整合性を維持できます。

> ロックで、整合性以外に思い浮かぶものがないんですけど。。。

ディレクトリ内の整合性を私は問題にしていません。
それはまぁ違う技術が解決してくれるでしょう。

私はAPIの設計理念に疑問をもっていたのです。
なんでこんな実装になっているの、と。
こっちのほうがいいんじゃないの、と。

>>「ディレクトリの共用アクセス制御」と厳密に表現したほうが良さそうですね。
>
> と言われても、共用アクセス制御って知らないですけど。。。
> MSDNライブラリで引いても出て来ないし。。。

うーん。「共有アクセス制御」かな？
Share Access Control。

#「共用」のほうが正しい気がしますが、「共有」の方が多いかな？

MSDNの中ではsharing modeだとかshare accessだとか、
あんまり統一してないようで、MS的正式名称は知りません。

引用返信 編集キー/

■20162 / inTopicNo.30)

　Re[19]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (15回)-(2008/06/06(Fri) 20:37:49)

■No20158 (れいさん) に返信
> いいえ。
> それは現状を維持する理由にはなりますが、選択する理由にはなりません。
> 前にも書いてますが。
> 他にもっといい方法があるように思えるのに、
> 敢えてこうなっている、合理的理由が欲しいわけです。

私には十分、選択する理由になりますけど。。。
デメリットがあってメリットがない実装は選択しない。

> >>ハンドルを開いている間はエントリの重複も抜けもチェックしなくてよいとか、
>>
>>抜けはチェックの仕様がないような。
>
> いいえ。
> 例えば。
> 「FileShare.Read」でディレクトリを開いた上でエントリの存在を確認すれば、
> ディレクトリハンドルを閉じるまではエントリの存在が保証される、
> そんな実装も可能です。

それは抜けないようにする対策でしょ？

読む前に抜けたものは、チェックの仕様がないと言ったのです。

読んだ後に抜ける話は、
|例えば、エントリを列挙して、アプリが何かの条件でエントリを絞り込んで、
|それを削除か更新しようとしたら、先に誰かが削除してた、とかいうシナリオを
|想定したのですが。。。
で言ったのですが、これはれいさんがそういう話じゃないと否定しましたよね？

> >>エントリの属性を適用する際に整合性を維持することもできるとか。
>>どういうことでしょう？
>
> ディレクトリのFileAttributesを設定して次にCreationDateを変更するときとか、
> 一度に出来ない作業の場合は排他で開けると整合性を維持できます。

その「整合性を維持できます」の意味というか、価値が分からないのですが、
逆に不整合というのはどういう状況で、どういう悪影響が考えられるのですか？

引用返信 編集キー/

■20164 / inTopicNo.31)

　Re[13]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ネタ好き (380回)-(2008/06/06(Fri) 20:50:40)

2008/06/06(Fri) 20:51:45 編集(投稿者)

私はUNIXの哲学を解説した本で、
UNIXは開発者を信頼して気に入らなければ自分でしなさい
Windowsはその逆で細かい事はマイクロソフトでやってやるから安心して開発しなさい。
※これはあくまで大意です。
というスタンスを取ると書いておりました。
私の感覚から言ってもそれは正しいと思います。
現にWindowsのAPIはラッパーにしか過ぎず、内部でNt〇〇のシステムコールは開発者に触らせないわけです。そのため何らかの前提(制約と言ってもいい)を設けています。
ですから、カーネルがディレクトリの共有を使用していても、ポリシーとして開発者には触らせないのではないでしょうか？（もちろん互換性の問題もあると思います）
マイクロソフトの気持ちを推測すると、へっぽこ開発者がディレクトリをロックしてしまえば、当然色々不都合が在ります。それにファイルをロックしてしまえば、その代替はある程度可能なのですから、へっぽこ開発者が犯す危険よりも利点が少ないと判断しているのでしょう。
無論これではアプリが想定していないファイルはロックできないでしょうが、そもそもアプリが把握していないファイルをロックするのは危険なので、それでもいいのでは無いでしょうか？

追伸
アプリ専用ユーザカウントを用意して、そのユーザ以外には一切アクセス出来ないようにすればいいのでは？

引用返信 編集キー/

■20173 / inTopicNo.32)

　Re[14]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ちゃっぴ (112回)-(2008/06/06(Fri) 23:54:24)

私も、Windows の file 制御に疑問を持っていた一人です。

せっかく file handle という良いものがあるのにそれをうまく生かし切れていないなぁと正直感じてました。

なんで file handle 使った削除できないの？とか。

> アプリ専用ユーザカウントを用意して、そのユーザ以外には一切アクセス出来ないようにすればいいのでは？

そういう次元の問題ではないと思います。同じ account でも process というか thread が違えば競合しますから。

引用返信 編集キー/

■20174 / inTopicNo.33)

　Re[15]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ネタ好き (381回)-(2008/06/07(Sat) 00:21:44)

私もNTのAPIには疑問をいっぱい持っています。でも実際問題デバイスドライバで色々な障害が起きたりしているんだから、へっぽこ開発者にファイルハンドルを自由にさせるのは怖いと思うよ。
もしさせるのなら、全ソースコードを明らかにして、自分で問題を解決できるようにしてくれなきゃ。
もういっそうの事Windowsが脱げば（ソースコードを公開すれば）全ての問題が解決する。
なーんてね。

引用返信 編集キー/

■20184 / inTopicNo.34)

　Re[20]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (602回)-(2008/06/07(Sat) 11:17:43)

■No20162 (すさん) に返信
> 私には十分、選択する理由になりますけど。。。
> デメリットがあってメリットがない実装は選択しない。

うーん。全部もう一度説明せねばなりませんか。

ディレクトリハンドルを使うようにして、共有アクセス制御を可能にした場合。
メリットは以前述べたいくつかの点と、実装が簡単に、綺麗になる点。
デメリットは行儀の悪いプログラムがあると少しうるさい点。
だと私は考えたわけです。

ディレクトリに共有アクセス制御を導入してパフォーマンスが落ちるのかどうかは、
なかなか微妙だろうと私は結論しています。

現在の実装は致命的な問題が無いことはわかっていますが、
どうしても「珍妙」な実装に見えます。

なので、「デメリットに比べメリットのほうが大きい」ように私には思えるので、
なぜ現在の仕様を選んだのか疑問なわけです。

私が思いついていない他のデメリットがあるのか、
それとも、なにか違う事情があったのか、
ただの偶然か。
そういう質問です。

「共有アクセス制御」を入れたら困るであろう点や、
歴史的事情、開発者の設計ポリシーなどを教えて欲しいと。

> それは抜けないようにする対策でしょ？
> 読む前に抜けたものは、チェックの仕様がないと言ったのです。

ええ。
ファイルハンドルを開くまえ、閉じた後はどうしょうもないですね。
開いている最中は消えて欲しくない、
という要望は叶えられます。

> その「整合性を維持できます」の意味というか、価値が分からないのですが、
> 逆に不整合というのはどういう状況で、どういう悪影響が考えられるのですか？

そのまんまです。
更新時刻や属性を重要なメタデータとして扱いたいときに、できたら便利なんですが。
今は出来ないので違う方法を使わざるを得ない。

■No20173 (ちゃっぴさん) に返信
> 私も、Windows の file 制御に疑問を持っていた一人です。

おぉ。
私のほかに一人いましたね。
私は「歴史的事情」でとりあえず納得できましたが、どうでしょう？

> せっかく file handle という良いものがあるのにそれをうまく生かし切れていないなぁと正直感じてました。
> なんで file handle 使った削除できないの？とか。

Vistaから、ようやくNtXXX使わなくてもできるようになりました。
「SetFileInformationByHandle」で「FileDispositionInfo」を指定すればOKです。

引用返信 編集キー/

■20185 / inTopicNo.35)

　Re[14]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (603回)-(2008/06/07(Sat) 11:31:09)

■No20164 (ネタ好きさん) に返信
> ですから、カーネルがディレクトリの共有を使用していても、ポリシーとして開発者には触らせないのではないでしょうか？（もちろん互換性の問題もあると思います）
> マイクロソフトの気持ちを推測すると、へっぽこ開発者がディレクトリをロックしてしまえば、当然色々不都合が在ります。それにファイルをロックしてしまえば、その代替はある程度可能なのですから、へっぽこ開発者が犯す危険よりも利点が少ないと判断しているのでしょう。

なぜ、ディレクトリのハンドルに対してだけそう判断したのかが分かりません。
そのポリシーが聞きたいです。
APIでShutdownやプロセス削除すらできます。
ちょっと変なWindowsメッセージを送るだけでクラッシュするような状態なのに、
たかがディレクトリのハンドルをいじらせないようにする理由にはならないでしょう。

> 無論これではアプリが想定していないファイルはロックできないでしょうが、そもそもアプリが把握していないファイルをロックするのは危険なので、それでもいいのでは無いでしょうか？

「そもそもアプリが把握していないファイルをロックするのは危険」
そうでしょうかねぇ？

それはそんな行為をするアプリが危険なんではないでしょうか？

ユーザーモードのアプリケーションが行儀が悪い動作をしたり、悪意があったりする場合に、
OSがどう対応するべきなのか、
というのに関しては、未だ一般的解決法はありません。
どのOSも模索状態だと思います。

それを意識してAPI設計したとは思えません。

引用返信 編集キー/

■20190 / inTopicNo.36)

　Re[15]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ちゃっぴ (114回)-(2008/06/07(Sat) 12:14:18)

■No20185 (れいさん) に返信
> 私は「歴史的事情」でとりあえず納得できましたが、どうでしょう？

列挙時の directory lock は列挙に関しては一貫性が保障されますが、扱うときに一貫性が保障されないので効果が薄いと判断されたんじゃ無いんですかね？
また、数十年前の PC の resource はそれこそ限られていましたから、できるだけ高速にというのが今以上に求められていたと思いますから、performance 劣化はできる限り避けたかったのでは？
それから、file 操作の一貫性保証がそこまで求められていなかったというのもあるかと思いますし。

また、多くの人が言及されていますが lock を柔軟に制御できるようにすると DB を扱うときのように blocking をものすごく気にしなければなりません。それを避けたかったというのも正直あるんじゃないかなぁ。

DB tuning でも blocking は最重要でかつ複雑な部類に分類されますし。

そういう意味では、WinFS が導入された状況を一度見てみたかったかも。

> Vistaから、ようやくNtXXX使わなくてもできるようになりました。
> 「SetFileInformationByHandle」で「FileDispositionInfo」を指定すればOKです。

うお！そんなのあったんだ。。。これは今まで無いのがおかしいと思っていました。
自分で lock したものを削除するのに Lock 解放してからじゃないと NG ってなによ！って感じてました。

引用返信 編集キー/

■20191 / inTopicNo.37)

　Re[16]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ネタ好き (382回)-(2008/06/07(Sat) 12:23:28)

2008/06/07(Sat) 12:24:46 編集(投稿者)

うーんマイクソフトの意図がつかみずらい・・・
私もあまり納得していないのですがロック粒度の問題は大きいと思います。
ロック粒度をディレクトリまで広げるとなると、個々のファイルへロックをかけるよりも、逆にパフォーマンスが向上する様に出来るかもしれませんが、やっぱり抵抗感がありますね。
へっぽこ開発者は問題外だけど、Windowsのようにソースコードを隠蔽されたら、ただでさえ難しいマルチスレッドの問題がより複雑になります。その際に粒度が大きいディレクトリを導入するとなると、やはり苦しいですね。
マイクロソフトの隠蔽体質が原因な気がします。
ただ、UNIXとは対極的はマイクロソフトの「開発者に楽をさせる」というのも利点がありますし、非常に難しいところですね。
もし楽が出来ないのならばパッチが出るたびにもっと恐慌状態になってしまうでしょうし・・・

引用返信 編集キー/

■20195 / inTopicNo.38)

　Re[21]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (16回)-(2008/06/07(Sat) 13:57:15)

■No20184 (れいさん) に返信

なかなか話がかみ合いませんね。感覚の違いかな？

例えば、れいさんは、

> 開いている最中は消えて欲しくない、
> という要望は叶えられます。

をメリットと感じているようですが、私にはデメリットに見えます。

あるアプリがディレクトリを開いていると、
別のアプリが処理を終えてファイルを削除しようするとエラーになる。
これは悪夢だ。

引用返信 編集キー/

■20196 / inTopicNo.39)

　Re[21]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (17回)-(2008/06/07(Sat) 14:11:20)

■No20184 (れいさん) に返信
> >>エントリの属性を適用する際に整合性を維持することもできるとか。
>>どういうことでしょう？
>
> ディレクトリのFileAttributesを設定して次にCreationDateを変更するときとか、
> 一度に出来ない作業の場合は排他で開けると整合性を維持できます。

>>その「整合性を維持できます」の意味というか、価値が分からないのですが、
>>逆に不整合というのはどういう状況で、どういう悪影響が考えられるのですか？
>
> そのまんまです。
> 更新時刻や属性を重要なメタデータとして扱いたいときに、できたら便利なんですが。
> 今は出来ないので違う方法を使わざるを得ない。

なにが問題なのか、なにが便利なのか、ちっとも分からないですが、
もうすこし明確にできませんか？

引用返信 編集キー/

■20197 / inTopicNo.40)

　Re[22]: ディレクトリの排他アクセス

▲　■

□投稿者/ れい (607回)-(2008/06/07(Sat) 14:21:54)

■No20195 (すさん) に返信
> なかなか話がかみ合いませんね。感覚の違いかな？

前提がだいぶ違うのではないかと。
でも、だからこその価値があると思います。
嫌でなければ互いに納得いく所まで話せれば。

> 例えば、れいさんは、
>
>>開いている最中は消えて欲しくない、
>>という要望は叶えられます。
>
> をメリットと感じているようですが、私にはデメリットに見えます。
>
> あるアプリがディレクトリを開いていると、
> 別のアプリが処理を終えてファイルを削除しようするとエラーになる。
> これは悪夢だ。

「できる」ことそのものは直接デメリットではありません。
「乱用可能」なことはデメリットですが。

つまり、「行儀の悪い」アプリケーションをどうするか、という問題になるのですよね？

「開いている最中は消えて欲しくない」という要望があったときに、
「できるけど、他のアプリが困る場合があるので注意しろ」という態度なのか、
「それは他のアプリで困る場合があるからサポートしない」という態度なのか。

もしマイクロソフトが後者の態度であったとするのなら、
ファイルシステムは前者の態度で組んでいるので、おかしいのです。

> あるアプリがディレクトリを開いていると、
> 別のアプリが処理を終えてファイルを削除しようするとエラーになる。
> これは悪夢だ。

何回も言ってますが、現実にディレクトリハンドルを開くことは可能ですので、
「悪」かどうかはともかく、「夢」じゃないですよ。
頻度の問題はありますが、現実です。

現実に可能なのに、Win32APIにないのかが疑問なのです。

引用返信 編集キー/

＜前の20件 | 次の20件＞
トピック内ページ移動 / << 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 >>

- Child Tree -