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

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

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

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


(過去ログ 40 を表示中)

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

■20414 / inTopicNo.81)  Re[30]: ディレクトリの排他アクセス
  
□投稿者/ れい (632回)-(2008/06/10(Tue) 15:16:44)
No20406 (す さん) に返信
> 解決済みなところにコメントするのも気が引けますが、どうもすっきりしないので。

どうぞどうぞ。
そろそろ落ちたかと思っただけですので。
疑問をもつ人がまだいるなら、解決ではないですね。

> 共用アクセスとか言われてもどうもぴんと来ません。
> どうもディレクトリをファイルと比較されてるような感じですが、

そうです。
ディレクトリとファイルを同等に扱えてもいいじゃないかと、ずっと言っています。

> そもそも比較するならデータベースなのでは?
> プライマリキーがファイル名のテーブル

DBとの比較はいろいろ楽しい話もあるでしょうが、また違う話です。
それを話しはじめるときりが無いので、
とりあえずファイルシステムに関してのみ、話をしましょう。

比喩や比較としてDBを出すなら…
「エントリ名,エントリ種別(ファイル/ディレクトリ)」
というテーブルをディレクトリごとに用意するようなDBか、
「ID, 親ディレクトリID, エントリ名, エントリ種別(ファイル/ディレクトリ)」
のようなテーブルになるかと思います。

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

んーと、す さんの答えはどれでしょう?
見当たらりません。

その「第一の理由」の教科書的答えはNTがMicroKernel戦略だからということになりますが、
その話をしだすと、話題からだいぶ逸れてしまいます。

とりあえず今話題にしている「ディレクトリの開き方」に最も関連してるものに限るなら、
前にも書いたようにSubSystemの話になると思います。
NTKernel層ではディレクトリはハンドルで開き、その際共用アクセス制御はあります。
Win32 SubSystem層になる際にそれは隠蔽され、FindXXXFileになってしまいます。
他のSubSystemでは、ディレクトリハンドルを開くことも可能なものもあります。
POSIX、Interix SubSystemなどでは、ハンドルを開けるようですが…、
詳しいことはよく分かりません。(あまり興味がわかないので調べていません)

引用返信 編集キー/
■20427 / inTopicNo.82)  Re[31]: ディレクトリの排他アクセス
□投稿者/ す (29回)-(2008/06/10(Tue) 15:43:45)
No20414 (れい さん) に返信
> ディレクトリとファイルを同等に扱えてもいいじゃないかと、ずっと言っています。

そこの違いですかね。

>>そもそも比較するならデータベースなのでは?
>>プライマリキーがファイル名のテーブル
>
> DBとの比較はいろいろ楽しい話もあるでしょうが、また違う話です。

いいえ、比較とかの話ではなくて、ディレクトリは昔からデータベースです。
商用DBMSが出来る前から。
なので、ディレクトリを商用DBMSの上に作ったらとかの話じゃないです。

>>あと、
>>OSがAPI層とシステム層を分離している第一の理由はなんだと思います?
>>私は一応、答えたつもり。
>
> んーと、す さんの答えはどれでしょう?
> 見当たらりません。

そこも違っているようですね。

第一の理由は、ユーザ/アプリに勝手なことをさせない。
ユーザ/アプリができることを絞り込んで、ユーザ/アプリが好き勝手しても、
システムはへいちゃらよ、とするための構造です。
NTができる前から。
引用返信 編集キー/
■20429 / inTopicNo.83)  Re[32]: ディレクトリの排他アクセス
□投稿者/ れい (633回)-(2008/06/10(Tue) 15:50:57)
No20427 (す さん) に返信
> いいえ、比較とかの話ではなくて、ディレクトリは昔からデータベースです。
> 商用DBMSが出来る前から。
> なので、ディレクトリを商用DBMSの上に作ったらとかの話じゃないです。

広義のデータベースの話ですか。

それなら当然ファイルシステムはデータベースです。
ディレクトリが出来る前から。
ロックとか共用アクセスとか言う前に。

> >>あと、
> >>OSがAPI層とシステム層を分離している第一の理由はなんだと思います?
> >>私は一応、答えたつもり。
>>
>>んーと、す さんの答えはどれでしょう?
>>見当たらりません。
>
> そこも違っているようですね。
>
> 第一の理由は、ユーザ/アプリに勝手なことをさせない。
> ユーザ/アプリができることを絞り込んで、ユーザ/アプリが好き勝手しても、
> システムはへいちゃらよ、とするための構造です。
> NTができる前から。


それは
> その「第一の理由」の教科書的答えはNTがMicroKernel戦略だからということになりますが、
ここに集約されてますが。

> そこも違っているようですね。

なにがなにと違ってるのでしょう?

というか、
何の話をしてるのですか?


引用返信 編集キー/
■20433 / inTopicNo.84)  Re[33]: ディレクトリの排他アクセス
□投稿者/ す (30回)-(2008/06/10(Tue) 16:34:33)
No20429 (れい さん) に返信

> 広義のデータベースの話ですか。
>
> それなら当然ファイルシステムはデータベースです。

また極端な。ディレクトリがキー付きレコードの集合体であることを指してます。

> ディレクトリとファイルを同等に扱えてもいいじゃないかと、ずっと言っています。

これが不思議なのです。
データベースとファイルを同等に扱えてもいいじゃないかと、
というように聞こえるのです。

>NTKernel層ではディレクトリはハンドルで開き、その際共用アクセス制御はあります。
>Win32 SubSystem層になる際にそれは隠蔽され、FindXXXFileになってしまいます。

は、なにか悪いことのような書き方ですが、

>それは
>> その「第一の理由」の教科書的答えはNTがMicroKernel戦略だからということになりますが、
>ここに集約されてますが。

なら、悪くないのでは?
引用返信 編集キー/
■20435 / inTopicNo.85)  Re[32]: ディレクトリの排他アクセス
□投稿者/ シャノン (467回)-(2008/06/10(Tue) 16:59:41)
No20427 (す さん) に返信
> いいえ、比較とかの話ではなくて、ディレクトリは昔からデータベースです。
> 商用DBMSが出来る前から。
> なので、ディレクトリを商用DBMSの上に作ったらとかの話じゃないです。

商用DBMSというのは何を指していますかね?
この際、「商用」という言葉は忘れるとして、「RDBMSという概念が出来る前から、ディレクトリはデータベースです」は正しいですか?
だとすると、そこには主キーとかいう概念があるかどうか怪しいと思いますけど。

> 第一の理由は、ユーザ/アプリに勝手なことをさせない。
> ユーザ/アプリができることを絞り込んで、ユーザ/アプリが好き勝手しても、
> システムはへいちゃらよ、とするための構造です。

ディレクトリハンドルを排他的に開けても、システムはへいちゃらよ、と思っている人とは平行線ですよね。
引用返信 編集キー/
■20438 / inTopicNo.86)  Re[34]: ディレクトリの排他アクセス
□投稿者/ れい (634回)-(2008/06/10(Tue) 17:16:05)
No20433 (す さん) に返信
>>ディレクトリとファイルを同等に扱えてもいいじゃないかと、ずっと言っています。
>
> これが不思議なのです。
> データベースとファイルを同等に扱えてもいいじゃないかと、
> というように聞こえるのです。

なるほど。
そこが疑問ですか。
それも何回も言ってるつもりですが。

> ■No20429 (れい さん) に返信
>
>>広義のデータベースの話ですか。
>>
>>それなら当然ファイルシステムはデータベースです。
>
> また極端な。ディレクトリがキー付きレコードの集合体であることを指してます。

ディレクトリはたしかにエントリを保持しますが、
それはテーブルというアナロジーとは完全には一致しません。
ディレクトリはそれ自身も属性と名称、親ディレクトリをもつわけで、
ディレクトリもファイルと同じディレクトリのエントリです。

操作をハンドルやファイルオブジェクトとして抽象化するなら、
ファイルシステム内のオブジェクトも

class FileSystemEntry {
public DateTime CreationDate;
...
}
class File : FileSystemEntry {
public Stream MainStream;
...
}
class Directory : FileSystemEntry {
public List<FileSystemEntry> Entries;
}

という感じで抽象化されてもよいのではないですか?
むしろ、そのほうが綺麗ではないですか?

例えば。
「c:\aaa\tmp」という「ファイル」がある場合、
「c:\aaa\tmp」という「ディレクトリ」を作ることはできませんよね?
パス名はファイルとディレクトリ共通で、重複する名前は作れません。

それを表現する際に「他のエントリと同名のエントリは作れません」と表現できるべきではないですか?
「他のファイルもしくは他のディレクトリと同名のファイルもしくは同名のディレクトリはつくれません」
というのは大変です。

後者の様な、めんどくさい実装になってると思いますか?

最初から作り直されたであろう.Netでも、
FileSystemInfo -> FileInfo, DirectoryInfo
という順に継承されていますよね。

> >NTKernel層ではディレクトリはハンドルで開き、その際共用アクセス制御はあります。
> >Win32 SubSystem層になる際にそれは隠蔽され、FindXXXFileになってしまいます。
>
> は、なにか悪いことのような書き方ですが、
>
> >それは
> >> その「第一の理由」の教科書的答えはNTがMicroKernel戦略だからということになりますが、
> >ここに集約されてますが。
>
> なら、悪くないのでは?

まず、さして重要でない齟齬を言うと。
ディレクトリハンドルを隠蔽しているのはWin32層です。NTカーネル内ではありません。
なので、隠蔽してもしなくても「カーネルの安定」とはほとんど関係ありません。

それと、本質が一つ。

よりシンプルで高機能な実装があるのにそれを隠蔽し、醜い実装になってるのは
歴史的にしょうがなかったとしても、それ自体は「ダメ」です。負の遺産です。

「普通に考えて」ファイルシステムエントリという概念を導入し、
ディレクトリはそのリストを保持すると考えたほうが合理的だと。

データベースのアナロジーで言うなら。

す さんは
「ファイル名,更新日時,アクセス日時,…」
というテーブルが、ディレクトリ毎に存在するだけのデータベースを考えてるようですが、
これではファイルシステムとしてうまく機能しません。

ファイル名と同じディレクトリが作れないことはどうやって確認しますか?
ディレクトリの属性や、細かい情報はどこに保存しますか?

少なくとも、
「エントリ名,エントリ種別(ファイル/ディレクトリ),更新日時,アクセス日時,…」
というように、エントリ毎のレコードにする必要があります。
エントリのテーブルをディレクトリ毎に作るべきです。

#FATはこうなってます。一方NTFSは全エントリが1テーブルです。

ディレクトリは属性をもっているのか、とか、
ファイル名と同じ名前のディレクトリが作れるかどうか、とか、
ディレクトリ自身がストリームを持ってもいいのか、とか、
そういったことはOSやファイルシステムによって違う場合もあるでしょうが。

少なくともWindowsのファイルシステムでは、ディレクトリとファイルはカーネルでほぼ同等に扱われています。

で、ディレクトリハンドルをAPIで使用可能にした場合、
どのくらいパフォーマンスが落ちる可能性があるのかは、不明です。

私の価値観では、
エントリのハンドルを開けるようにして得られる「綺麗さ」は、
ロックによりパフォーマンスが落ちるであろう「懸念」を、
圧倒的に上回ります。

しかし、DOSとの互換性と言われると…。諦めざるを得ません。
盲腸も盲点も口蓋垂も私は要りませんが、
イカやミミズから生まれなおすわけにいかないので。
引用返信 編集キー/
■20439 / inTopicNo.87)  Re[33]: ディレクトリの排他アクセス
□投稿者/ れい (635回)-(2008/06/10(Tue) 17:21:58)
No20435 (シャノン さん) に返信
> ■No20427 (す さん) に返信
>>いいえ、比較とかの話ではなくて、ディレクトリは昔からデータベースです。
>>商用DBMSが出来る前から。
>>なので、ディレクトリを商用DBMSの上に作ったらとかの話じゃないです。
>
> 商用DBMSというのは何を指していますかね?
> この際、「商用」という言葉は忘れるとして、「RDBMSという概念が出来る前から、ディレクトリはデータベースです」は正しいですか?
> だとすると、そこには主キーとかいう概念があるかどうか怪しいと思いますけど。

そういう議論を始めると、すごく大変になります。
NTFSの由来だとか、WinFSの実装だとか、そういう話に。

#それも話を聞きたいところではありますが。

でもとりあえずWindowsでは
「同じ名前のエントリは存在しない」
「アクセスはエントリの名前で行う」
ということになってますので、
エントリの名前は主キーであろうと思います。

そこに「親ディレクトリまでのパス」を含めるかどうかいろいろ議論の余地がありますが。

ちなみに、NTFSなどでは「エントリのID」でのアクセスの方が速いです。
ただ、このIDは恒常性が無くても許される(リブートすると値が変わる)ので、
主キーといっていいのか微妙です。

引用返信 編集キー/
■20443 / inTopicNo.88)  Re[34]: ディレクトリの排他アクセス
□投稿者/ シャノン (469回)-(2008/06/10(Tue) 17:40:22)
No20439 (れい さん) に返信
> そういう議論を始めると、すごく大変になります。
> NTFSの由来だとか、WinFSの実装だとか、そういう話に。

そっちの方まで話を広げる気はないです。
「ディレクトリはデータベース」と言うとき、その「データベース」は、RDBMS を指しているのか、そうでないのか、そこだけ明確にしようと思って。
引用返信 編集キー/
■20446 / inTopicNo.89)  Re[33]: ディレクトリの排他アクセス
□投稿者/ れい (637回)-(2008/06/10(Tue) 17:51:27)
そうそう。

No20435 (シャノン さん) に返信
>>第一の理由は、ユーザ/アプリに勝手なことをさせない。
>>ユーザ/アプリができることを絞り込んで、ユーザ/アプリが好き勝手しても、
>>システムはへいちゃらよ、とするための構造です。
>
> ディレクトリハンドルを排他的に開けても、システムはへいちゃらよ、と思っている人とは平行線ですよね。

排他的に開けることにより、どのくらいシステムがダメになるか、
という話に関しては実証も実測も困難です。

ですから、
パフォーマンスがそれほど落ちないであろうという私の予想を押し付ける気はありません。
私の予想は、思いつく限りの論拠を述べました。
その論拠にたいする反論や、気づいていない点があるなら、議論したいと思っています。

#まだ私が返していない反論は「ロックの粒度」ですね。

「絶対にパフォーマンスが落ちる」と思っていて、且つ「その根拠を言わない」のであれば、
それは信じる人ですので、議論する気はありません。
「平行線」ですから。

でも、す さんはそういう態度ではないので、平行線ではありません。
私の説明が下手なこともあり、だいぶぐるぐる回ってますが。

> ディレクトリハンドルを排他的に開けても、システムはへいちゃらよ、と思っている人とは平行線ですよね。

思ってるだけでは平行線ではありませんよ。
根拠無く信じるのなら平行線ですが。
引用返信 編集キー/
■20447 / inTopicNo.90)  Re[35]: ディレクトリの排他アクセス
□投稿者/ 渋木宏明(ひどり) (778回)-(2008/06/10(Tue) 17:59:45)
渋木宏明(ひどり) さんの Web サイト
> 最初から作り直されたであろう.Netでも、

最初から作り直されてはいないです。
.NET の BCL は、Win32 の上に作られてます。

BCL がカーネル層の API を呼び出すことは今後もないと思います。

> よりシンプルで高機能な実装があるのにそれを隠蔽し、醜い実装になってるのは
> 歴史的にしょうがなかったとしても、それ自体は「ダメ」です。負の遺産です。

ではあっても、既に FindXXXFile() が存在している以上、同じ目的を持つ新 API セットを追加する可能性は薄いと思います。
(FindXXXFile() が「今よりももっと駄目なモノ」だったらその可能性もあったかもしれませんが)

今さら FindXXXFile() を廃止することはできない(=既存アプリが動かなくなります)し、(表面上)ファイル名の列挙程度の目的で FindXXXFile() と新 API が共存させる、というのは、多数の開発者を混乱させる(=MSのサポートコスト増)」と判断されると思います。

件名の「ディレクトリの排他アクセス」についても少し考えてみましたが

・「ディレクトリ丸ごと」というのは排他の粒度として適切か?大きすぎないか?
・その割に、排他を許した場合の影響範囲が広いので、可・不可の制御が現行のディレクトリ属性や ACL で間に合うのか?

なんて点が気になり、即座にはコミットできません。

追加するなら、ディレクトリに対する TxF とかそういう方向の方がよいのかもしれません。

引用返信 編集キー/
■20448 / inTopicNo.91)  Re[34]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (421回)-(2008/06/10(Tue) 18:05:36)
ファイルシステムは階層型データベースだと思います。
引用返信 編集キー/
■20454 / inTopicNo.92)  Re[33]: ディレクトリの排他アクセス
□投稿者/ す (31回)-(2008/06/10(Tue) 18:41:13)
No20435 (シャノン さん) に返信
> 商用DBMSというのは何を指していますかね?

トランザクション機能など商用DBMSが当たり前に持ってる機能を持ってるDBMS
なんて言ったら駄目?

> この際、「商用」という言葉は忘れるとして、「RDBMSという概念が出来る前から、ディレクトリはデータベースです」は正しいですか?
> だとすると、そこには主キーとかいう概念があるかどうか怪しいと思いますけど。

DBMSが出来る前、データベースとして使っていたのは、
キー付きレコードの集合体
ISAM
VSAM KSDS
POファイルのディレクトリ
など

ディレクトリに相当するカタログはVSAM KSDS
VSAMが出来る前はキー付きDAMとか???
末端のディレクトリに相当するVTOCもキー付きのDSCB集合体

VSAMには代替キーが付けれたかの知れませんが、他はキーが一つなので
主キーじゃないかも知れませんが。。。
引用返信 編集キー/
■20455 / inTopicNo.93)  Re[35]: ディレクトリの排他アクセス
□投稿者/ す (32回)-(2008/06/10(Tue) 18:56:21)
No20443 (シャノン さん) に返信
> 「ディレクトリはデータベース」と言うとき、その「データベース」は、RDBMS を指しているのか、そうでないのか、そこだけ明確にしようと思って。

「ディレクトリはデータベース」と言うと語弊があるので撤回しときます。

要は、ディレクトリはキー付きレコードの集合体で、同時多重にアクセスされる、
みたいなことが言いたいわけです。

引用返信 編集キー/
■20456 / inTopicNo.94)  Re[34]: ディレクトリの排他アクセス
□投稿者/ す (33回)-(2008/06/10(Tue) 18:59:55)
No20439 (れい さん) に返信
> ちなみに、NTFSなどでは「エントリのID」でのアクセスの方が速いです。
> ただ、このIDは恒常性が無くても許される(リブートすると値が変わる)ので、
> 主キーといっていいのか微妙です。

どっかのRDBMSのRow IDみたいなものですかね。これは永続性があったような。

脱線しました。
引用返信 編集キー/
■20457 / inTopicNo.95)  Re[35]: ディレクトリの排他アクセス
□投稿者/ す (34回)-(2008/06/10(Tue) 19:21:59)
No20438 (れい さん) に返信
> ディレクトリはたしかにエントリを保持しますが、
から
> 後者の様な、めんどくさい実装になってると思いますか?

ここの意図がわかりませんでした。。。

> まず、さして重要でない齟齬を言うと。
> ディレクトリハンドルを隠蔽しているのはWin32層です。NTカーネル内ではありません。
> なので、隠蔽してもしなくても「カーネルの安定」とはほとんど関係ありません。

NTカーネル内だけがシステム層ではなく、外側にもシステム層があって、
そこもユーザ/アプリに勝手にされないよう、APIを絞り込みます。
この部分はハード的には守られないので、紳士協定的ではありますが。。。

> す さんは
> 「ファイル名,更新日時,アクセス日時,…」
> というテーブルが、ディレクトリ毎に存在するだけのデータベースを考えてるようですが、

いいえ

> これではファイルシステムとしてうまく機能しません。
>
> ファイル名と同じディレクトリが作れないことはどうやって確認しますか?
> ディレクトリの属性や、細かい情報はどこに保存しますか?
>
> 少なくとも、
> 「エントリ名,エントリ種別(ファイル/ディレクトリ),更新日時,アクセス日時,…」
> というように、エントリ毎のレコードにする必要があります。
> エントリのテーブルをディレクトリ毎に作るべきです。

そんな感じです。
が、別にDBMS上にディレクトリを作ろうとしてる訳ではないので。。。

> で、ディレクトリハンドルをAPIで使用可能にした場合、
> どのくらいパフォーマンスが落ちる可能性があるのかは、不明です。

DBMSで、テーブル全体の更新意図ロックを取るようなものだと思います。
あるディレクトリを使う人がすべて更新意図ロックを取れば。。。

> 私の価値観では、
> エントリのハンドルを開けるようにして得られる「綺麗さ」は、
> ロックによりパフォーマンスが落ちるであろう「懸念」を、
> 圧倒的に上回ります。

エントリのハンドルというのがよく分かりませんが、
インスタンスロックがあればいいなぁという話なら理解できます。

引用返信 編集キー/
■20460 / inTopicNo.96)  Re[34]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (423回)-(2008/06/10(Tue) 20:06:32)
実装方法によっては、ディレクトリにロックを掛ける方がパフォーマンスが向上すると思うのですが、Windowsはどうなっているのですか?
引用返信 編集キー/
■20463 / inTopicNo.97)  Re[36]: ディレクトリの排他アクセス
□投稿者/ れい (638回)-(2008/06/10(Tue) 21:39:03)
No20447 (渋木宏明(ひどり) さん) に返信
>>最初から作り直されたであろう.Netでも、
>
> 最初から作り直されてはいないです。
> .NET の BCL は、Win32 の上に作られてます。
>
> BCL がカーネル層の API を呼び出すことは今後もないと思います。

語弊がありましたね。
Win32を捨てて、という意味ではありません。
Win32の縛りはあるでしょうが、
その上に新たに一層作る際に、
ディレクトリとファイルとを包括するFileSystemInfoを作ったというところが主張したい点です。

>>よりシンプルで高機能な実装があるのにそれを隠蔽し、醜い実装になってるのは
>>歴史的にしょうがなかったとしても、それ自体は「ダメ」です。負の遺産です。
>
> ではあっても、既に FindXXXFile() が存在している以上、同じ目的を持つ新 API セットを追加する可能性は薄いと思います。
> (FindXXXFile() が「今よりももっと駄目なモノ」だったらその可能性もあったかもしれませんが)

そうですね。残念ながら。
だからこそ、負の遺産ですね。
なので、今から実装すべき、という主張をしたいわけではないです。

ただ、導入するのに必要な変更はエントリの列挙用のAPI一つ追加するだけです。
「APIセット」というほど大げさなものではありません。
開発者をそれほど混乱させること無く追加することは可能だと思います。
SetInformationと同程度の手間ではないかなぁと、勝手に思ってます。

> 件名の「ディレクトリの排他アクセス」についても少し考えてみましたが
>
> ・「ディレクトリ丸ごと」というのは排他の粒度として適切か?大きすぎないか?
> ・その割に、排他を許した場合の影響範囲が広いので、可・不可の制御が現行のディレクトリ属性や ACL で間に合うのか?
>
> なんて点が気になり、即座にはコミットできません。

では、最初から作り直す場合、どう実装しますか?
ファイルとディレクトリと、別にするのは無駄だと私は思いますが。

また、排他対象、粒度もいろいろあるでしょう。
ディレクトリ以下全てアクセス制御するのか、
ディレクトリ直下のみなのか、
ディレクトリそのものだけか。(つまり、属性だとかReparseTagへのアクセスのみ制御される)

私は最後のでもいいと思います。

ファイルとディレクトリで「違いすぎる」ので疑問だったのです。

No20457 (す さん) に返信
>>少なくとも、
>>「エントリ名,エントリ種別(ファイル/ディレクトリ),更新日時,アクセス日時,…」
>>というように、エントリ毎のレコードにする必要があります。
>>エントリのテーブルをディレクトリ毎に作るべきです。
>
> そんな感じです。

ならば「ファイルもしくはディレクトリを開く」ことを
「レコードを開く」と対応させるのですよね。

で、「共用アクセス制御」はレコードを開くときに行われるのですから。
ファイルだけでなくディレクトリを開くときにも「共用アクセス制御」できて然るべきだと思いますが。

> DBMSで、テーブル全体の更新意図ロックを取るようなものだと思います。
> あるディレクトリを使う人がすべて更新意図ロックを取れば。。。

テーブル全体ではないですよね。
あるディレクトリ以下のレコード全てかもしれないし、
あるディレクトリ直下のレコードかもしれない。
それは実装次第でしょうが、少なくともテーブル全体ではない。

>>私の価値観では、
>>エントリのハンドルを開けるようにして得られる「綺麗さ」は、
>>ロックによりパフォーマンスが落ちるであろう「懸念」を、
>>圧倒的に上回ります。
>
> エントリのハンドルというのがよく分かりませんが、
> インスタンスロックがあればいいなぁという話なら理解できます。

ファイルもしくはディレクトリをエントリと呼んでます。
で、ファイルとディレクトリと同様に扱えないのは何故?という話をしてるので
開くときには「エントリのハンドルを開く」と表現してます。

ロック、ロックと騒いでますが、
ロックそのものよりも、ファイルとディレクトリとで違うことを問題にしています。
なので別にインスタンスロックが欲しいわけではありません。

どんなロックでもいいのです。
再帰的にロックがかかっても、直下だけでも、かまいません。
もしロックの粒度が大きくて問題なら
ディレクトリの属性にアクセスする際にしかロックの影響がなくてもかまいません。

CreateFileで、共用アクセス制御を用いてディレクトリを開けないことを疑問に思ってるのです。

ディレクトリに共用アクセス制御があったときに、
ディレクトリ内のエントリはどう制御されるべきか、
というのはとりあえずどうでもいいです。

引用返信 編集キー/
■20467 / inTopicNo.98)  Re[37]: ディレクトリの排他アクセス
□投稿者/ 渋木宏明(ひどり) (780回)-(2008/06/10(Tue) 22:31:48)
渋木宏明(ひどり) さんの Web サイト
2008/06/10(Tue) 22:34:19 編集(投稿者)

> Win32の縛りはあるでしょうが、
> その上に新たに一層作る際に、
> ディレクトリとファイルとを包括するFileSystemInfoを作ったというところが主張したい点です。

1層位の上乗せだと、どうしても直下の層の影響が出ちゃいますからね。
かといって、汎用性が重要な場面で上乗せの層を厚くすると、融通が利かなくなって破たんしてしまうこともあるし。

> では、最初から作り直す場合、どう実装しますか?
> ファイルとディレクトリと、別にするのは無駄だと私は思いますが。

ディレクトリのロックを許すかどうかを別にして、ってことでよければ、ディレクトリエントリの読み出しは、ファイルアクセスと相似であっても別によかったと思います。(の方がよい、と言うほど強いこだわりはありません)

引用返信 編集キー/
■20468 / inTopicNo.99)  Re[38]: ディレクトリの排他アクセス
□投稿者/ ネタ好き (424回)-(2008/06/10(Tue) 22:44:05)
2008/06/10(Tue) 22:45:16 編集(投稿者)

>ロックそのものよりも、ファイルとディレクトリとで違うことを問題にしています。
違うのも案外悪い事では無いと私は思います。もともとディレクトリは、確かUNIXでユーザで一つの空間を共有するさいに「ファイル名が同じだと困る」(一階層ディレクトリシステム)と言う事で開発された概念だと聞いております。
それで当然、ユーザごとにディレクトリをつくろうと言う発想になりできたのが二階層ディレクトリシステムです。これは未だにUNIX系OSに残っている概念です。
この次に「同じユーザでもファイル名が重なると困るよね」と言う事で、ディレクトリの中にディレクトリを作ることが許可されたわけです。それが現在の階層型ディレクトリシステムです。
ですから、ファイルとディレクトリは似ておりますが元々生まれが違うののであって、
ファイルシステム上ファイルとディレクトリが同じに見えてもやはり「違う概念」なのです。
従ってAPIが違うのも一理あると思います。
それに、ディレクトリをロックする際には、やはり【下層をどうするのか】という問題が発生しますので、前に私が言った問題点をスマートにマイクロソフトが解決できない限り導入するのは危険なのです。
もし私が実装するのならばやは階層型+りリレーショナル型+XML型を参考に、次世代のファイルシステムを作ると思います。
OSの設計思想を変えない限り表面的な改良はしてはならないと私は思います。
引用返信 編集キー/
■20470 / inTopicNo.100)  Re[39]: ディレクトリの排他アクセス
 
□投稿者/ れい (639回)-(2008/06/10(Tue) 23:29:41)
2008/06/10(Tue) 23:38:15 編集(投稿者)
2008/06/10(Tue) 23:38:01 編集(投稿者)

No20468 (ネタ好き さん) に返信
> OSの設計思想を変えない限り表面的な改良はしてはならないと私は思います。

何回も言ってますが、
FATとNTFSの設計思想ではディレクトリもファイルもファイルシステムエントリです。

> ですから、ファイルとディレクトリは似ておりますが元々生まれが違うののであって、
> ファイルシステム上ファイルとディレクトリが同じに見えてもやはり「違う概念」なのです。

元々違う出自でとうぜん違うものですが、同じ部分もありますよ?
両方ともファイルシステムのエントリです。

共通部分を抜き出し、
両方を包含する概念として管理するのは当然ではないですか?

で、実際NTは同じものとして管理してるのですよ。

OSの設計思想が「同じもの」ならAPIも「同じもの」であるべきではありませんか?
変じゃありませんか?
だから質問したのですが。

なかなか話が通じないですねぇ…
読み直してみたんですが。
私が書いた文章はそんなに意味不明だとは思わないんですけどねぇ。

引用返信 編集キー/

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

管理者用

- Child Tree -