この質問kernel.dllは、 を使用して、ファイル名などのファイル属性を再帰的に見つけるための迅速な方法を提供します。問題は、進行状況の報告 (Windows フォーム アプリなど) が、現在のファイルまたはディレクトリに限定されていることです。これは、前もって合計ファイル数に関する情報がないためです。
ただし、Windows 7 でファイル エクスプローラーを使用してファイルを検索すると、検索の進行状況バーが表示されます。
では、彼らはここでどのようにそれを行うのでしょうか? 総ファイル数は事前にわかっていますか? 上記の質問への回答で、この種の進捗報告を模倣することは可能ですか? 事前に合計ファイル数を知らずにそれを行う方法がわかりません。
私が見つけることができた最も近い質問は、フォルダー数が前もってないため、この再帰メソッドにいくつかの問題があるように見えるこれであり、多くのファイルの単一のディレクトリの動作は非常に奇妙です。
取得する必要がある精度に応じて、単純な 2 パス ソリューションがある場合があります (ネットワーク ドライブには最適ではないため、そこで調整する必要がある場合があります)。
ディレクトリの最初のnレベル (ドライブを含めて 4 など) について、サブディレクトリの数を数えます。これは通常は迅速な操作ですが、たとえば 5 つ以上のサブディレクトリが存在する場合や同様の場合にのみ再帰するように微調整できます。この番号を保存します。
n実際の検索を実行するときは、ルートのステップ内にある、完了したサブディレクトリの数を追跡してください。この数と保存されたカウントを使用して、完了を推定します。
たとえば、基本構造では次のようになります。
C:\
a\
1\
i\
ii\
iii\
2\
3\
b\
c\
a、1を数える、 iと兄弟を無視する、 2を数える、など。 次に、検索中に、 3、2、1、aなどを検索し終わったら、バーを増やします。
さて、これは絶対に確実ではありません。競合状態があるかもしれません、それはひどく正確ではありません、そしてあらゆる種類のものです。
ただし、粒度の低い進行状況バーの場合、かなり正確に見えるほど十分に近いです。さらに重要なのは、ユーザー エクスペリエンスの観点から、保存されたカウントを使用して進行状況を比較すると、プロセスの途中でバーが大きくなるのを防ぐ傾向があることです。
私は実際にこのテクニックをいくつかのコードで使用しています。
最初のビルドは 10 レベル下がりますが、それでもかなり高速です。どれだけのテストが行われたかは覚えていませんが、250 万から 300 万のファイルを検索するとき、バーは視覚的に正確であり、多くの一時停止がありません (事前にその 1/1000 しかチェックしていないにもかかわらず)。プログレスバーが短いほど、より正確に表示されることに注意してください。;)
検索しているディレクトリの下のファイルをカウントするスレッドをバックグラウンドで開始します。バックグラウンドで、これまでにカウントされたファイルの数を更新します。プログレスバーでこのカウントを使用します。この数が1を超えると、検索を安全に開始できます。進行状況を計算するとき、検索が（奇跡的に）バックグラウンドファイルカウンターを上回っている場合、または進行状況バーで時折目に見える余談が許容できない場合は、結果をファッジします。
これにより、ファイルをカウントする最速の方法を見つけることができます（FindFirstFileExを検討してください）。ローカルドライブでは、プログラムファイルなどのフォルダをカウントするのに2〜3秒かかる場合があります。ネットワーク上では、FindFirstFileExを使用すると、ファイルの数とディレクトリのリストのみが必要な場合にファイル名が送信されるため、さらに時間がかかります。
これはすべて、ファイルを数えるだけでなく、検索に多くの時間を費やすことを前提としています。