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

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

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

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


(過去ログ 40 を表示中)

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

■20223 / inTopicNo.61)  Re[22]: ディレクトリの排他アクセス
  
□投稿者/ れい (617回)-(2008/06/07(Sat) 17:07:30)
No20220 (ネタ好き さん) に返信
> 私の感覚としてはファイルシステムは階層型データベースで、自分でOSを作る際にはリレーショナルデータベースにしたいと何年もずっと思っていたので、ディレクトリがそのように公開されていないのは、「階層型データベース」だからのような気がします。
> 階層型データベースは仕組みが分かっていれば効率的なのですが、そうで無い場合は非効率的かつ危険になってしまいます。
> とくにロック作業は構造を熟知しないと危険です。

reparseだとかjunctionだとか、いろいろ技術があるところからすると、
もしかしたら本質的に非階層なファイルシステムの方がいいのかもしれませんが…
RDBなFSはあまりうれしくないです。
いろいろ相性が悪いので…

> だから秘密主義のマイクロソフトは公開して上手く操作してもらう事よりも「隠して使わせない」戦略をとった気がします。
> れいさんは考えはどちらかというとUNIX的で「仕組みを積極的に使用させる」という方針だと思いますが、マイクロソフトはきっと「絶対必要で無い限り隠して使わせない」と考えるのだと思います。

ふーむ。なるほど。

ひどりさんの言っていた「消極的理由」の一つに入るかもしれません。

「積極的理由が無い限りは何か危険があるかもしれないので開示しない」
という、昔のMSの戦略・スタンスですね。
引用返信 編集キー/
■20224 / inTopicNo.62)  Re[23]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (384回)-(2008/06/07(Sat) 17:15:31)
2008/06/07(Sat) 17:17:14 編集(投稿者)

階層型で閃きました。
マイクロソフトは、開発したアプリよりも上の階層でロックされた場合の事も考えたのでしょう。アプリの開発者は自分より上の階層の事や下の階層に注意を向けません。何故ならば、「インストール場所はユーザーの自由」だからです。この様な状態ではよほど注意深い開発者で無いと対応できません。
では注意深い人の為にAPIを何故出さないのかと言う事になると思いますが、そこはプログラマの本能と関係していると思います。プログラマは、APIがあれば「とにかく使いたい衝動に駆られる」のです。
ですから好奇心猫を殺す状態のAPIに飢えた危険なプログラマから末端のユーザを守るために、WinAPIをあえて作らなかったと思います。そうしないとマイクロソフトの評判はがた落ちです。
引用返信 編集キー/
■20225 / inTopicNo.63)  Re[28]: ディレクトリの排他アクセス
□投稿者/ れい (618回)-(2008/06/07(Sat) 17:19:03)
No20222 (す さん) に返信
>>
>>だから…
>>
>>MSは必要としていたのです。
>>なので、ファイルシステムではディレクトリへの排他アクセスが必須になっています。
>>なのに、Win32APIには無いのです。
>
> だから、
> MS自身が「そういうWin32API」を特に必要としてなかったからでしょう。
> だから、Win32APIには無いのです。

4周目くらいですね。

「必要ない」では理由にならないのです。

私はロックを実装しなかった理由を聞いてるのではありません。
より低い実装コストで、ロックが可能な実装もあったはずなのに、
それを選ばなかった理由を聞いてるのです。

赤い扉と緑の扉があります。
あなたはせっかくなので赤いほう選ぶことにしました。

「君はなぜ赤い扉を選んだんですか?」
「緑を選ぶ必要がなかったからです」

という会話は意味がありませんよね?

「赤が好きだから」とか「赤い扉の方が軽かった」とか
「緑は取っ手が汚かった」とか、「ずっと赤いほうを選んでるから」とか、

合理的理由が必要です。
通じたでしょうか?
引用返信 編集キー/
■20227 / inTopicNo.64)  Re[23]: ディレクトリの排他アクセス
□投稿者/ 渋木宏明(ひどり) (775回)-(2008/06/07(Sat) 17:36:13)
渋木宏明(ひどり) さんの Web サイト
ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
引用返信 編集キー/
■20228 / inTopicNo.65)  Re[29]: ディレクトリの排他アクセス
□投稿者/ す (24回)-(2008/06/07(Sat) 17:41:10)
No20225 (れい さん) に返信
> 赤い扉と緑の扉があります。

もそっと明確にしてもらえません?

ひとつのディレクトリエントリに対する排他的アクセスのWin32APIを作るか
作らないかの選択なら
必要性を認めなかったのでしょうとしか言いようないと思いますが。。。

ディレクトリに対する、他者の読み取り可、書き込み可の、
ディレクトリエントリを列挙するWin32API
と他の実装、例えば、
ディレクトリに対する、他者の読み取り可、書き込みを禁止して、
ディレクトリエントリを列挙、読み取り、書き込みするWin32API
を比べているのですか?
引用返信 編集キー/
■20230 / inTopicNo.66)  Re[24]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (385回)-(2008/06/07(Sat) 18:03:52)
>ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?

これは、すさんに向けてのメッセージですよね?
すさん返事した方がいいと思うよ。

引用返信 編集キー/
■20231 / inTopicNo.67)  Re[30]: ディレクトリの排他アクセス
□投稿者/ れい (619回)-(2008/06/07(Sat) 18:40:05)
No20228 (す さん) に返信
> ■No20225 (れい さん) に返信
>>赤い扉と緑の扉があります。
>
> もそっと明確にしてもらえません?

私としてはこれ以上ないくらい明確にしてるつもりですが、
伝わらないということは、私とす さんでは「明確」の意味する所がずれてるのでしょうねぇ。

じゃあ。
もそっとがんばってみます:D

> ひとつのディレクトリエントリに対する排他的アクセスのWin32APIを作るか
> 作らないかの選択なら
> 必要性を認めなかったのでしょうとしか言いようないと思いますが。。。

存在しないことの積極的理由は「必要が無い」で構いません。
PCに尻尾がない理由は「必要が無い」しかありません。

ですから、
「こんなAPIがなぜ無いんだ!」と騒いでるのなら、
「必要が無い」でいいのです。

> ディレクトリに対する、他者の読み取り可、書き込み可の、
> ディレクトリエントリを列挙するWin32API
> と他の実装、例えば、
> ディレクトリに対する、他者の読み取り可、書き込みを禁止して、
> ディレクトリエントリを列挙、読み取り、書き込みするWin32API
> を比べているのですか?

いいえ。
エントリ列挙や属性設定などのディレクトリに対する操作をする際に、
ディレクトリハンドルを通じて制御する方法と、
FindFirstFileなどのディレクトリ専用のAPI群で制御する方法を比較しています。

私は、前者の方が単純で分かりやすく、素直であると思っています。
オッカムの剃刀みたいな話です。


No20230 (ネタ好き さん) に返信
> >ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
>
> これは、すさんに向けてのメッセージですよね?

いや、私では?自意識過剰ですか?

No20227 (渋木宏明(ひどり) さん) に返信
> ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?

列挙したら半分くらい抜けてしまう程度には把握してます。
かなりの理由がSubSystemのせいだと思っています。

で、OS/2やPOSIX、SFUなどのSubSystemも調べてるんですが…
あまりしっかりとはできてません。

POSIXやSFUはディレクトリもハンドルで開いてるようです。
が、共有アクセス制御の概念が無いので、全部共有で開いています。

OS/2サブシステムは、資料がなくてまだ調べられていません。
かなり気になってるんですが。


引用返信 編集キー/
■20233 / inTopicNo.68)  Re[31]: ディレクトリの排他アクセス
□投稿者/ す (25回)-(2008/06/07(Sat) 19:17:34)
No20231 (れい さん) に返信

>なぜ、APIには排他的にディレクトリを開く方法が用意されていないのでしょうか?

と仰るので

>>ディレクトリに対する、他者の読み取り可、書き込み可の、
>>ディレクトリエントリを列挙するWin32API
>>と他の実装、例えば、
>>ディレクトリに対する、他者の読み取り可、書き込みを禁止して、
>>ディレクトリエントリを列挙、読み取り、書き込みするWin32API
>>を比べているのですか?

と思ったのですが、

> エントリ列挙や属性設定などのディレクトリに対する操作をする際に、
> ディレクトリハンドルを通じて制御する方法と、
> FindFirstFileなどのディレクトリ専用のAPI群で制御する方法を比較しています。

ということなら、昔からそれがあったからですね。きっと。
引用返信 編集キー/
■20234 / inTopicNo.69)  Re[31]: ディレクトリの排他アクセス
□投稿者/ す (26回)-(2008/06/07(Sat) 19:26:34)
No20231 (れい さん) に返信
> ■No20230 (ネタ好き さん) に返信
>>>ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
>>
>>これは、すさんに向けてのメッセージですよね?
>
> いや、私では?自意識過剰ですか?
>
> ■No20227 (渋木宏明(ひどり) さん) に返信
>>ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
>
> 列挙したら半分くらい抜けてしまう程度には把握してます。

それは「理由」ではないのでは?
どうしてOSがWin32 API 層と NT カーネル層をわざわざ分離しているのか?
という質問です。
引用返信 編集キー/
■20235 / inTopicNo.70)  Re[32]: ディレクトリの排他アクセス
□投稿者/ れい (621回)-(2008/06/07(Sat) 19:37:43)
No20233 (す さん) に返信
> ■No20231 (れい さん) に返信
>
> >なぜ、APIには排他的にディレクトリを開く方法が用意されていないのでしょうか?
>
> と仰るので

あーなるほど。
この文が誤解の元ですか。

確かに誤解を生む表現ですね。
すみません。

No20234 (す さん) に返信
>>■No20227 (渋木宏明(ひどり) さん) に返信
> >>ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
>>
>>列挙したら半分くらい抜けてしまう程度には把握してます。
>
> それは「理由」ではないのでは?
> どうしてOSがWin32 API 層と NT カーネル層をわざわざ分離しているのか?
> という質問です。

理由を質問したのではなくて
理由を知ってるかどうかを確認しただけでしょう。文字通り。

「Win32 API 層と NT カーネル層が分離されている理由」を把握してないと
ファイルシステムは云々という私の話に全く意味がありませんし、
分離されてる理由を知っていればそこから知見を得られるかもしれないよという
アドバイスであろうと解釈してます。
引用返信 編集キー/
■20237 / inTopicNo.71)  Re[25]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (386回)-(2008/06/07(Sat) 22:15:38)
ちょっと疑問に思ったのですが、マーケティング的な合理的判断と、技術的な合理的判断がありえるわけですが、れいさんはどちらを想定しておりますか?マイクロソフトの様な超巨大企業ともなれば、その二つを切り離して語るのは不可能だと思います。だから技術的合理性が感じられない点が多々あるのだと私は思っています。
引用返信 編集キー/
■20238 / inTopicNo.72)  Re[32]: ディレクトリの排他アクセス
□投稿者/ す (27回)-(2008/06/07(Sat) 22:17:18)
No20233 (す さん) に返信
>>エントリ列挙や属性設定などのディレクトリに対する操作をする際に、
>>ディレクトリハンドルを通じて制御する方法と、
>>FindFirstFileなどのディレクトリ専用のAPI群で制御する方法を比較しています。
> ということなら、昔からそれがあったからですね。きっと。

実際のところはそうなんでしょうが、もし、過去にしがらみがなく、
あたらしくOSを作るとしたらどっちで作るかという質問なら、
後者ですね。
理由は、そのほうが機能が絞られている。より抽象化されている。などでしょうか。

> >ちなみに、Win32 API 層と NT カーネル層が分離されている理由は把握してるんですよね?
>これは、すさんに向けてのメッセージですよね?
>すさん返事した方がいいと思うよ。

こんな返事でいかがでしょう?
引用返信 編集キー/
■20240 / inTopicNo.73)  Re[33]: ディレクトリの排他アクセス
□投稿者/ れい (622回)-(2008/06/07(Sat) 23:06:24)
No20237 (ネタ好き さん) に返信
> ちょっと疑問に思ったのですが、マーケティング的な合理的判断と、技術的な合理的判断がありえるわけですが、れいさんはどちらを想定しておりますか?マイクロソフトの様な超巨大企業ともなれば、その二つを切り離して語るのは不可能だと思います。だから技術的合理性が感じられない点が多々あるのだと私は思っています。

なんでもOKです。
政治的でも経済的でも技術的でも学術的でもなんでも。
合理的でさえあれば。

No20238 (す さん) に返信
> 実際のところはそうなんでしょうが、もし、過去にしがらみがなく、
> あたらしくOSを作るとしたらどっちで作るかという質問なら、
> 後者ですね。
> 理由は、そのほうが機能が絞られている。より抽象化されている。などでしょうか。

後者ですか?!
そっちのほうが抽象化されてますか?!

不思議です。
私は前者の方が汎的であり、抽象化されてると思うのですが。
引用返信 編集キー/
■20241 / inTopicNo.74)  Re[26]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (387回)-(2008/06/07(Sat) 23:28:13)
了解しました。まずは次の事をみんなで考えたら話しが進むと思います。

・ディレクトリをロックする場合、自分より下層にはどう対処したらいいか?
・ディレクトリを上層で勝手にロックされた場合どうすればいいのか?
・あぷりの最終的なユーザーは他の分野の人だから技術力が無くて、何も考えずにアプリを思った場所にインストールするけど、それによりどういった問題が起こり、どう対処すればいいのか?
・上記3つの解決法は簡単なのか?
・解決法を開発者ユーザに守らせることが出来るのか?
・問題が発生した場合マイクソフトとしてはどう対処するべきなのか?

この6点を考えたら技術的側面とマーケティング的側面を網羅した議論ができると思います。
引用返信 編集キー/
■20245 / inTopicNo.75)  Re[31]: ディレクトリの排他アクセス
□投稿者/ シャノン (460回)-(2008/06/08(Sun) 01:14:05)
No20231 (れい さん) に返信
>>ひとつのディレクトリエントリに対する排他的アクセスのWin32APIを作るか
>>作らないかの選択なら
>>必要性を認めなかったのでしょうとしか言いようないと思いますが。。。
>
> 存在しないことの積極的理由は「必要が無い」で構いません。
> PCに尻尾がない理由は「必要が無い」しかありません。
>
> ですから、
> 「こんなAPIがなぜ無いんだ!」と騒いでるのなら、
> 「必要が無い」でいいのです。

よくないですよね。
「ディレクトリハンドルを通じてファイルを列挙するようなAPIがなぜ無いんだ!」「必要ないからです」じゃだめですよね。
「(カーネル内部ではディレクトリハンドルというものがあるのに)それを活用してファイルを列挙するAPIがなぜ無いんだ!(なぜディレクトリハンドルをわざわざ隠蔽しているんだ!)」ということでしょう。
それは「どうして一回呼ぶ毎に俺の給料が倍になるようなAPIがないんだ!」とは前提が違う話ですよね。

PCのしっぽの話でいえば、「CPUにはしっぽ用のバスがあるのに、どうしてしっぽ用の穴があいているケースがひとつもないんだ!」みたいな話だと思います(バスがあればね)。
CPUにしっぼ用のバスがある場合とない場合とでは、「どうしてケースに穴がないんだ!」と嘆く理由が全然違ってきます。
引用返信 編集キー/
■20246 / inTopicNo.76)  Re[32]: ディレクトリの排他アクセス
□投稿者/ れい (623回)-(2008/06/08(Sun) 02:07:44)
No20245 (シャノン さん) に返信
> それは「どうして一回呼ぶ毎に俺の給料が倍になるようなAPIがないんだ!」とは前提が違う話ですよね。

確かに。
それは必須ですよね。
ない理由がわからない。
どんな実装より優先して開発して頂きたい。

実は既にあるけど非公開なのかもしれませんが。

> CPUにしっぼ用のバスがある場合とない場合とでは、「どうしてケースに穴がないんだ!」と嘆く理由が全然違ってきます。

そういえば、尻尾用の穴が開いたケース、どなたかお持ちでしたね。
写真を見たことがあるような。

みなさんも一度PCケースの中を確認したほうがいいですよ。
CPUにしっぽがあった場合、ケースの中はもふもふになってるかもしれません…

天国。
解決済み
引用返信 編集キー/
■20250 / inTopicNo.77)  Re[27]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (389回)-(2008/06/08(Sun) 12:25:41)
あのぉーれいさん、どのように解決したのか教えてくれたら在り難いのですが・・・
解決済み
引用返信 編集キー/
■20252 / inTopicNo.78)  Re[33]: ディレクトリの排他アクセス
□投稿者/ シャノン (461回)-(2008/06/08(Sun) 13:04:38)
No20246 (れい さん) に返信
> ■No20245 (シャノン さん) に返信
>>それは「どうして一回呼ぶ毎に俺の給料が倍になるようなAPIがないんだ!」とは前提が違う話ですよね。
>
> 確かに。
> それは必須ですよね。
> ない理由がわからない。
> どんな実装より優先して開発して頂きたい。
>
> 実は既にあるけど非公開なのかもしれませんが。

わはは、違いない。

>>CPUにしっぼ用のバスがある場合とない場合とでは、「どうしてケースに穴がないんだ!」と嘆く理由が全然違ってきます。
>
> そういえば、尻尾用の穴が開いたケース、どなたかお持ちでしたね。
> 写真を見たことがあるような。
>
> みなさんも一度PCケースの中を確認したほうがいいですよ。
> CPUにしっぽがあった場合、ケースの中はもふもふになってるかもしれません…

これからの時期、大変なことになりますよ。もふもふは。
引用返信 編集キー/
■20258 / inTopicNo.79)  Re[28]: ディレクトリの排他アクセス
□投稿者/ れい (624回)-(2008/06/08(Sun) 18:37:21)
2008/06/08(Sun) 18:37:38 編集(投稿者)

No20250 (ネタ好き さん) に返信
> あのぉーれいさん、どのように解決したのか教えてくれたら在り難いのですが・・・

あー。前回の解決済みと大して変わってないのですが。
一応まとめます。

私の勝手な予想も混ざってますが、
以下のように解決しました。

・DOS Ver. 2で。
階層ファイルシステムとファイルハンドルが導入された際、
ディレクトリ名をFindFirstFile/FindNextFileシステムコールに指定することで列挙するように実装された。
(これの理由は不明。)
ファイルはハンドルから開くよう変更された。

・DOS Ver. 3で。
ファイルハンドルに共用アクセス制御が導入されたが、
ディレクトリは従来のまま、名称からの列挙だった。

・Win16導入の際、恐らく「DOSとの互換性」と「実装のコスト」のため
ディレクトリハンドルは導入されず、相変わらずFindXXXFileを使ったAPIだった。

・Me/98/95のファイルシステムでディレクトリハンドルがあったかは不明だが、
Win32cでもディレクトリハンドルは導入されない。

・NTもしくはOS/2のファイルシステムでは、かなり初期からディレクトリもファイルシステムも
共用アクセス制御が導入されており、(NT3では既にあった。OS/2は不明。)
OSが利用している。

・が、NT以降のWin32も、主にWin32cとの互換性のため、ディレクトリハンドルによる列挙は導入されていない。

・ディレクトリの共用アクセス制御をユーザープログラムに公開することで
パフォーマンスがどのくらい落ちるのかは不明。
ユーザープログラム次第。

・互換性以外に考慮すべき要素は
無くても何とかなる
ロックの実装の仕方など、考慮したり周知したりするコストがある
より強力な大体手段が既にある

・後から作られたNTでは導入されているので、
全てを捨てて新たにWinAPIを作るなら、恐らくディレクトリにも共用アクセスが導入される。
つまり、そのほうが「シンプルで美しい」。

・尻尾はこれからの時期、おすすめできない

そんな感じです。
どうもありがとうございました。
解決済み
引用返信 編集キー/
■20406 / inTopicNo.80)  Re[29]: ディレクトリの排他アクセス
 
□投稿者/ す (28回)-(2008/06/10(Tue) 14:27:00)
No20258 (れい さん) に返信
解決済みなところにコメントするのも気が引けますが、どうもすっきりしないので。

共用アクセスとか言われてもどうもぴんと来ません。
どうもディレクトリをファイルと比較されてるような感じですが、
そもそも比較するならデータベースなのでは?
プライマリキーがファイル名のテーブル

あと、
OSがAPI層とシステム層を分離している第一の理由はなんだと思います?
私は一応、答えたつもり。
引用返信 編集キー/

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

管理者用

- Child Tree -