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

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

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

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

(過去ログ 40 を表示中)

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

■20602 / inTopicNo.121)

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

▼■

□投稿者/ ネタ好き (437回)-(2008/06/12(Thu) 18:53:57)

2008/06/12(Thu) 18:57:18 編集(投稿者)

■No20597 (れいさん) に返信
成る程。分かりやすい分析有難うございます。
ユーザー/カーネル切替が1回減るのは確かに利点ですよね。
この構造を見ていて一つ気になったのですが、この構造はメタ情報が増減する場合に不利ですよね。
でもマイクロソフトは検索を重視するためにこの構造を変えるかもしれませんね。
そうなると、FindFirstFileは過去の遺物となり、新しいAPIが提供される事になるのかな？
れいさんはFindFirstFileの未来の展望をどう思われますか？

追記
この質問はマイクロソフトの行為がただの失敗だったのか考えるためです。もし強固に保守するのならばFindFirstFileのこの動作は我々が考えている以上に重要なのに違い無いと考えたのです。

引用返信 編集キー/

■20610 / inTopicNo.122)

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

▲▼■

□投稿者/ れい (651回)-(2008/06/12(Thu) 21:52:27)

■No20602 (ネタ好きさん) に返信
> 2008/06/12(Thu) 18:57:18 編集(投稿者)
>
> ■No20597 (れいさん) に返信
> 成る程。分かりやすい分析有難うございます。
> ユーザー/カーネル切替が1回減るのは確かに利点ですよね。
> この構造を見ていて一つ気になったのですが、この構造はメタ情報が増減する場合に不利ですよね。

いいえ。
ディレクトリに保持するのに比べ、
エントリに保持するほうが、メタ情報の項目数の変更は楽です。

> でもマイクロソフトは検索を重視するためにこの構造を変えるかもしれませんね。
> そうなると、FindFirstFileは過去の遺物となり、新しいAPIが提供される事になるのかな？

現行のNTFSでは別ストリームで「EA(拡張属性)」「HardLink」「ReparseTag」「SparseFile」などの情報を保持しています。
ディレクトリ列挙時(FindFirstFile)に得られる「更新日時」などは別の場所に保持されています。
WinFSがぽしゃった今、当面この構造は変わらないと思います。

> れいさんはFindFirstFileの未来の展望をどう思われますか？
>
> 追記
> この質問はマイクロソフトの行為がただの失敗だったのか考えるためです。もし強固に保守するのならばFindFirstFileのこの動作は我々が考えている以上に重要なのに違い無いと考えたのです。

それは私の疑問が解決せねば私には分かりません。
それを質問していると言い換えてもほぼ同値です。

現在すら正確に把握できない私に未来を聞かないでください。
むしろ、教えていただきたく。

引用返信 編集キー/

■20623 / inTopicNo.123)

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

▲▼■

□投稿者/ ネタ好き (438回)-(2008/06/13(Fri) 08:38:45)

れいさんへ返信
私は技術的側面よりもビジネス的な方面を考えてみたのですが、マイクロソフトがこの様な構造にしたわけに特許は考えられないでしょうか？
商用UNIXがi-node構造を特許をとっていれば、マイクロソフトとしては違う構造を考えるしか無いと思います。

引用返信 編集キー/

■20718 / inTopicNo.124)

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

▲▼■

□投稿者/ れい (659回)-(2008/06/13(Fri) 20:29:42)

■No20623 (ネタ好きさん) に返信
> れいさんへ返信
> 私は技術的側面よりもビジネス的な方面を考えてみたのですが、マイクロソフトがこの様な構造にしたわけに特許は考えられないでしょうか？
> 商用UNIXがi-node構造を特許をとっていれば、マイクロソフトとしては違う構造を考えるしか無いと思います。

そういう話もあるかもしれませんが、
FindFirstFileやディレクトリハンドルの話とは直接関係なさそうですね。

引用返信 編集キー/

■20721 / inTopicNo.125)

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

▲▼■

□投稿者/ ネタ好き (443回)-(2008/06/13(Fri) 23:02:45)

2008/06/13(Fri) 23:39:14 編集(投稿者)

■No20718 (れいさん) に返信
> そういう話もあるかもしれませんが、
> FindFirstFileやディレクトリハンドルの話とは直接関係なさそうですね。

もしかしたら特許を侵害しないためにあの様な実装になったのかもしれません。
でもそれじゃ面白くないので、時間が空いたからちょっと調べてみます。

引用返信 編集キー/

■20723 / inTopicNo.126)

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

▲▼■

□投稿者/ ネタ好き (444回)-(2008/06/14(Sat) 00:11:16)

2008/06/14(Sat) 00:13:24 編集(投稿者)

調べて分かった事を列挙します。

１、ディレクトツリーの走査を行うためにFindFirstFile、FindNextFile、FindClose関数の３っつで１組の関数を提供している。

２、他のディレクトリ操作について
・ディレクトリの作成と削除が出来る。
・カレントディレクトリの設定と、カレントディレクトリの検出が出来る。
・ディレクトリ内のファイルの検索。
・ファイルとディレクトリに加えられた変更の非同期検出が出来る。

この一連のWinAPIを見て私が受ける印象は、マイクロソフトは目的を絞って「概念を提供している」と言う事です。では、何故ファイルは共用でオープンできて、ディレクトリはオープンできないのでしょうか？
その答えはこの機能リストにあると思います。ディレクトリはファイルのようにデータの入れ物としてではなく、あくまでもファイルの格納場所として扱い検索に機能を絞っている点が目立ちます。
このことからマイクソフトの意思はディレクトリは読むものではなくて、中にあるファイルをしまう場所だと明確に目的付けしていると私は考えました。
ディレクトリの共有読み込みが出来ないわけは、ファイルの格納場所という概念としてユーザーに提供しているからでは無いでしょうか？

引用返信 編集キー/

■20729 / inTopicNo.127)

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

▲▼■

□投稿者/ シャノン (476回)-(2008/06/14(Sat) 03:21:46)

■No20723 (ネタ好きさん) に返信
> その答えはこの機能リストにあると思います。ディレクトリはファイルのようにデータの入れ物としてではなく、あくまでもファイルの格納場所として扱い検索に機能を絞っている点が目立ちます。

つまり、ディレクトリはあくまでディレクトリであって、決してファイルの親戚ではないんだ、という意図を表明したいのではないか、ということでしょうか？

> ２、他のディレクトリ操作について
> ・ディレクトリの作成と削除が出来る。
> ・カレントディレクトリの設定と、カレントディレクトリの検出が出来る。
> ・ディレクトリ内のファイルの検索。
> ・ファイルとディレクトリに加えられた変更の非同期検出が出来る。

・CreateFile で開くことができる
・属性を取得／設定することができる
・作成日時、更新日時、最終アクセス日時を取得／設定することができる

も追加。
あれ、ファイルと似てきたね。

引用返信 編集キー/

■20731 / inTopicNo.128)

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

▲▼■

□投稿者/ ネタ好き (445回)-(2008/06/14(Sat) 09:18:08)

■No20729 (シャノンさん) に返信

>・CreateFile で開くことができる
CreateFileはディレクトリを指定するとINVALID_HANDLE_VALUEを返すよ。

>・属性を取得／設定することができる
>・作成日時、更新日時、最終アクセス日時を取得／設定することができる
そっそっそれは、検索する際にはファイルなのかディレクトリなのか分からないから、同じAPIで属性が取得出来るんじゃないかな(´ﾍ｀；)

>あれ、ファイルと似てきたね。
に似ているだけだよ(；´Д`A ```

引用返信 編集キー/

■20732 / inTopicNo.129)

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

▲▼■

□投稿者/ れい (661回)-(2008/06/14(Sat) 09:34:01)

■No20729 (シャノンさん) に返信
> ■No20723 (ネタ好きさん) に返信
>>その答えはこの機能リストにあると思います。ディレクトリはファイルのようにデータの入れ物としてではなく、あくまでもファイルの格納場所として扱い検索に機能を絞っている点が目立ちます。
>
> つまり、ディレクトリはあくまでディレクトリであって、決してファイルの親戚ではないんだ、という意図を表明したいのではないか、ということでしょうか？
>
>>２、他のディレクトリ操作について
>>・ディレクトリの作成と削除が出来る。
>>・カレントディレクトリの設定と、カレントディレクトリの検出が出来る。
>>・ディレクトリ内のファイルの検索。

・ディレクトリ内のエントリの列挙。

>>・ファイルとディレクトリに加えられた変更の非同期検出が出来る。

・ディレクトリ内のエントリの「サイズ」「属性」「名前」「セキュリティ属性」の変更や
「作成」「削除「名前の変更」「書き込み」の検出ができる

> ・CreateFile で開くことができる

・FILE_FLAG_BACKUP_SEMANTICSを指定すればCreateFileで開くことができる

> ・属性を取得／設定することができる
> ・作成日時、更新日時、最終アクセス日時を取得／設定することができる

+名前・場所を変更することが出来る

すさんの言っていた「属性などは全部ディレクトリに保存されてる(ように振舞うべき)」
というのと
ネタ好きさんの言う「ディレクトリとファイルが違うことを明示する」
というのが有力に感じてきました。

「FindFirstChangeNotification」も「対象ディレクトリ」に対する変更は検出できない様ですし。

引用返信 編集キー/

■20735 / inTopicNo.130)

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

▲▼■

□投稿者/ ネタ好き (447回)-(2008/06/14(Sat) 11:34:06)

＞・FILE_FLAG_BACKUP_SEMANTICSを指定すればCreateFileで開くことができる

しまった！忘れてた。シャノンさん失礼しました。

引用返信 編集キー/

■20738 / inTopicNo.131)

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

▲▼■

□投稿者/ す (39回)-(2008/06/14(Sat) 14:08:12)

2008/06/14(Sat) 14:14:07 編集(投稿者)

FindFirstFile()などが内部的にディレクトリハンドルを使っているというのは
確かなことなんでしょうか？
ディレクトリハンドルはバックアップ、リストアなどのユーティリティ用に
仮想的にでっち上げたものじゃないんですかね。
ZwQueryDirectoryFileはXP以降で使えると書いてあるし、
これもユーティリティ用にサポートしたんじゃないですかね。

追記
「仮想的にでっち上げたもの」
データベースのアンロード、ロード用データストリームみたいな

引用返信 編集キー/

■20739 / inTopicNo.132)

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

▲▼■

□投稿者/ す (40回)-(2008/06/14(Sat) 14:21:11)

■No20623 (ネタ好きさん) に返信
> 商用UNIXがi-node構造を特許をとっていれば、マイクロソフトとしては違う構造を考えるしか無いと思います。

i-nodeって、真似したくなるようないいようなものじゃなかったのでは？

引用返信 編集キー/

■20740 / inTopicNo.133)

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

▲▼■

□投稿者/ す (41回)-(2008/06/14(Sat) 14:43:31)

■No20480 (ネタ好きさん) に返信
> WindowsOSがディレクトリとファイルを同一に扱うのは【効率】的であるからであって、APIとして公開する部分については【概念】を提供しているわけですから、ディレクトリとファイルの扱いに明確に一線を引いているのではないかと私は推測しています。

違うものを同じに扱いたいというほうが理解できないです。
ファイルはユーザが勝手に使えばよいわけですが、
ディレクトリはシステムの持ち物で、勝手に使われては困ると思うのですが。
データベースファイルがCreateFile()でオープンできるからと言って、
DBMSがファイルハンドルベースのAPIを提供すべきだと言ってるような。

引用返信 編集キー/

■20741 / inTopicNo.134)

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

▲▼■

□投稿者/ れい (662回)-(2008/06/14(Sat) 14:57:54)

2008/06/14(Sat) 15:27:36 編集(投稿者)
■No20738 (すさん) に返信
> 2008/06/14(Sat) 14:14:07 編集(投稿者)
>
> FindFirstFile()などが内部的にディレクトリハンドルを使っているというのは
> 確かなことなんでしょうか？

はい。確かです。

> ディレクトリハンドルはバックアップ、リストアなどのユーティリティ用に
> 仮想的にでっち上げたものじゃないんですかね。
> ZwQueryDirectoryFileはXP以降で使えると書いてあるし、
> これもユーティリティ用にサポートしたんじゃないですかね。

いいえ。
ディレクトリハンドルが本質です。

どの層を考えるかによるかと思いますが。

ディレクトリハンドルはファイルシステムレベルではNT3.xの時代から、あります。
Win32サブシステム、つまりcsrssレベルでいつからあるのかは分かりません。

また、
Win32のCreateFileで開くことのできるハンドルは
ファイルシステムレベルでのハンドルと一致し、
これはディレクトリも同様です。

> ZwQueryDirectoryFileはXP以降で使えると書いてあるし、
> これもユーティリティ用にサポートしたんじゃないですかね。

ZwQueryDirectoryFileをサポートしたのはXP以降ですが。
(この例は適切ではありませんでした。下記のようにNtQueryDirectoryFileにしておくべきでした)

csrssや他のサブシステムがディレクトリ列挙をする際には
ntdll.dllの「NtCreateFile」で「ディレクトリハンドル」を開き、
「NtQueryDirectoryFile」にそれを指定して列挙します。
これはNT3時代から共通です。

下から順に考えると、ディレクトリをハンドルで扱っているのは
・ファイルシステムドライバ
・ntdll
であって、その上に載っているWin32サブシステムでは、部分的にしか使っていません。

ですので、より本質的であるのは「ディレクトリハンドル」です。
FindFirstの返すハンドルの方こそが当に「でっち上げたもの」です。

引用返信 編集キー/

■20742 / inTopicNo.135)

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

▲▼■

□投稿者/ れい (663回)-(2008/06/14(Sat) 15:19:36)

■No20740 (すさん) に返信
> ■No20480 (ネタ好きさん) に返信
>>WindowsOSがディレクトリとファイルを同一に扱うのは【効率】的であるからであって、APIとして公開する部分については【概念】を提供しているわけですから、ディレクトリとファイルの扱いに明確に一線を引いているのではないかと私は推測しています。
>
> 違うものを同じに扱いたいというほうが理解できないです。
> ファイルはユーザが勝手に使えばよいわけですが、
> ディレクトリはシステムの持ち物で、勝手に使われては困ると思うのですが。
> データベースファイルがCreateFile()でオープンできるからと言って、
> DBMSがファイルハンドルベースのAPIを提供すべきだと言ってるような。

良いとか悪いとか、納得いくかいかないかという話は置いといて。

すさんは「ディレクトリ」と「ファイル」を包含する概念として「ファイルシステムエントリ」を考えるのが
意味が無いと思うわけですよね。
私は意味があると思いますが。

現実には、ntdllの層までは「ファイルシステムエントリ」として扱っています。
つまり、ntdllを設計した人は、「意味がある」と思っていたことになります。

で、一方、Win32の層では「ファイルシステムエントリ」が
「ファイル」と「ディレクトリ」に分かれてしまっている、というのも現実です。
つまり、Win32を設計した人は、「わかれていたほうがいい」と「積極的に」思っていたことになります。

ここで設計理由・思想が変わってるわけですよね。

その差、本質的理由が知りたいのです。
「違うものを同じに扱いたいというほうが理解できないです。」
という理由は、同じ主張がWin32だけでなくntdllやFSDにも当てはまります。
Win32だけ違う理由としては説得力がありません。

ntdllまでの層と、Win32とで、設計が違う理由は何でしょう？

いままで出てきたように「歴史的理由」も理に適ってはいますが、
それならFindFirstFileをサポートした上で
ディレクトリハンドルも開けるようになってもいい。
なので、これも根拠としては少し弱い。

なんか簡単な理由がありそうなんだけど。

引用返信 編集キー/

■20743 / inTopicNo.136)

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

▲▼■

□投稿者/ す (42回)-(2008/06/14(Sat) 16:26:48)

■No20742 (れいさん) に返信
> なんか簡単な理由がありそうなんだけど。

ユーザのclose忘れを嫌ったのでは？

引用返信 編集キー/

■20744 / inTopicNo.137)

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

▲▼■

□投稿者/ れい (664回)-(2008/06/14(Sat) 16:54:23)

2008/06/14(Sat) 16:59:21 編集(投稿者)

■No20743 (すさん) に返信
> ■No20742 (れいさん) に返信
>>なんか簡単な理由がありそうなんだけど。
>
> ユーザのclose忘れを嫌ったのでは？

それはもう何回もループしてますよ。

それはファイルと同じでは？
Read/Write共有で開いておけば忘れてもたいして影響ないのでは？
それも嫌うなら、ディレクトリはRead/Write共有でないと開けないようにしてもいいのでは？
なぜ、ディレクトリだけclose忘れを嫌うのですか？
他にもclose忘れたらやばいものはたくさんあるのに、どうしてそちらは気にしないのでしょう？

引用返信 編集キー/

■20746 / inTopicNo.138)

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

▲▼■

□投稿者/ す (43回)-(2008/06/14(Sat) 18:02:41)

■No20744 (れいさん) に返信
> それはファイルと同じでは？
> Read/Write共有で開いておけば忘れてもたいして影響ないのでは？
> それも嫌うなら、ディレクトリはRead/Write共有でないと開けないようにしてもいいのでは？
> なぜ、ディレクトリだけclose忘れを嫌うのですか？
> 他にもclose忘れたらやばいものはたくさんあるのに、どうしてそちらは気にしないのでしょう？

そこがファイルと違うところで、
｜ファイルはユーザが勝手に使えばよいわけですが、
｜ディレクトリはシステムの持ち物で、勝手に使われては困ると思うのですが。

システムが使いたいときに使えないのが嫌なのでは？

システムがユーザのファイルを使うのはSummaryInfoなどがありますが、
それらが使えないときは、簡単に諦めればいいのですが、
ディレクトリの場合は、そうそう簡単に諦められないのではないでしょうか。

引用返信 編集キー/

■20748 / inTopicNo.139)

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

▲▼■

□投稿者/ れい (665回)-(2008/06/14(Sat) 18:53:56)

■No20746 (すさん) に返信
> そこがファイルと違うところで、
> ｜ファイルはユーザが勝手に使えばよいわけですが、
> ｜ディレクトリはシステムの持ち物で、勝手に使われては困ると思うのですが。
> システムが使いたいときに使えないのが嫌なのでは？

おぉ！
それは斬新。
考えたこともありませんでした。

でもそれはおかしいですね。

Win32以外のサブシステムではディレクトリハンドルが開けます。
また、システムにWin32サブシステムしか存在しなかったとしても、
デバイスドライバなど、MSの管轄外のコンポーネントがあり、
それらは当然ディレクトリをハンドルで扱います。
場合によっては排他で開くこともあります。

なので、Win32配下でディレクトリ専有を禁止しても、
ディレクトリが必ず使えるという保証は無く、
ならばディレクトリ専有を禁止する理由にはなりません。

実際、ページファイルを扱う場合を除いて、
システムのどのコンポーネントも、
ファイルやディレクトリが確実に使えることを前提に作られてはいません。

また、その説は「ディレクトリをハンドルで扱わないようにする」ことを支持するものではありません。
ディレクトリをハンドルで扱ったとしても、排他アクセスを禁止することは容易に可能です。

#現在CreateFileがBackupSemanticsでないとディレクトリを開けないように、
#ディレクトリを開くときはRead/Write共用でないと開けないようにすればいいだけです。

なので、その説は
「ディレクトリを排他で開けない」理由にも、
「ディレクトリをハンドルで扱えない」理由にもなってないですね。

引用返信 編集キー/

■20754 / inTopicNo.140)

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

▲　■

□投稿者/ ネタ好き (449回)-(2008/06/14(Sat) 21:06:54)

＞ntdllまでの層と、Win32とで、設計が違う理由は何でしょう？

まさか開発チームが違うからだという理由ではないですよね・・・

引用返信 編集キー/

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

- Child Tree -