|
■No20064 (y4yama さん) に返信
> ■No20042 (れい さん) に返信
>>ファイルハンドルと同様にも導入していれば、
>>ファイルもディレクトリも同等に扱うAPIになっていたかもしれない。
> 手元に1997年のwin32 APIオフィシャルリファレンスがあって、CreateFileを何気なく見たら
> ディレクトリハンドルを返すことが記載されています。（1997では、NTに限るとあるような、？）
はい。
ディレクトリハンドルを取得することは可能です。排他で開くことも可能です。
ですが、そこからエントリのリストを得るのはめんどくさい方法しかありません。
> どうも、９５，９８では欠如してて、NT,2000以降では同等に扱うAPIに（現在）なっている・・という
> 解釈はできないでしょうか？ （私が、変な勘違いをしておりましたら、お許しください）
はい。
NT系では内部でほぼ同等に扱っています。
95系はよくわかりません。
私はユーザーモードアプリケーションが通常使うであろうAPIで同等になっていない、
ということを問題にしています。
ディレクトリ内のファイルリストを得るのに、今はFindXXXFike系のAPIを使います。
しかし私は、
CreateFileでディレクトリハンドルを開きそのハンドルを指定してFindFirstFileを呼ぶ、
というような実装の方が綺麗で分かりやすいと思うのです。
■No20068 (す さん) に返信
>普通に考えてディレクトリロックなんて傍迷惑な機能はないほうがよいのでは？
その考えは全然「普通」ではないと私は思っています。
まず、ディレクトリを排他で開く機能は「すでにあります」。
OSは利用しています。
必要ないから実装してないということにはなりません。
また、ファイルIOはいつ失敗するか分かりませんので、
ディレクトリのエントリ列挙をするときには例外がおきたときの処理を入れる必要があります。
この処理が適切に入っていれば、ディレクトリの排他ロックがあっても問題なく動作します。
「他のひとはエラー対処で大変なことに」というのは間違いです。
同様に、再試行もデッドロックの検出も、今でも行わなければいけない事項です。
つまり、今現在適切にファイルIOを処理をしているプログラムにとっては、
ディレクトリの排他ロックが可能であってもコード量は変化しません。
大変なことにはなりません。
ですので、私は、「普通に考えて」ディレクトリを排他で開けるOSの方がよいと思ったわけです。
問題になるとするなら、774RRさんやPATIOさんの言うように、
共有違反やアクセス違反が頻発してしまってファイルIOに不具合が生じたり、パフォーマンスが悪くなる、
という点です。
どの程度悪くなるのかは実際にやってみないとわかりません。
OS作成者がどう判断してもおかしくありませんが、
私はあまり問題にならないと予想しています。
y4yamaさんのリンク先、NyaRuRuさんの記事でも述べられていますが、
ディレクトリが開かれているためにフォルダが削除できなくなることは現在でもありますが、
あまり問題になっていません。
ファイルを排他で開いても、それほど問題になりません。
ですので、孫子まで自動でロックするような実装にならない限り、
それほど大きな問題にはならないと思います。
ちなみに、NTFSでディレクトリハンドルを排他で開いても、サブディレクトリはロックされません。
|
