0

私の目的のために、Windows の NTFS ファイル システム上の特定のフォルダーからサブフォルダーを再帰的に列挙する方法を最適化する方法を探していました。Microsoft のFindFirstFile APIのページから、この小さな「宝石」に出くわしました。

注 まれに、または負荷の高いシステムでは、この関数が呼び出された時点で、NTFS ファイル システムのファイル属性情報が最新でない場合があります。現在の NTFS ファイル システムのファイル属性を確実に取得するには、GetFileInformationByHandle関数を呼び出します。

だから、それを理解しようとしましょう。

dwFileAttributes構造体で返されるパラメーターに依存してWIN32_FIND_DATA、フォルダーからファイルを伝えます。このメモが示唆しているのは、場合によっては偽の結果が得られる可能性があるということですよね? もしそうなら、ここに投稿するのではなく、彼らのアップデートで修正してみませんか?

また、GetFileInformationByHandle API を使用するための推奨される回避策もあります。正確にはどのように呼ぶべきですか？ファイルハンドルを取ります。FindNextFileでは、が返す各ファイルを開いて呼び出すことを本当に望んでいるのGetFileInformationByHandleでしょうか。私の最適化がそのようなアプローチで「どこまで」進むか想像できますか?

とにかく、誰かがこれに光を当てることができればいいのですが...

4

3 に答える 3

4

その情報は一定である可能性が高いため、フォルダーからファイルを区別することは問題ありません。ファイルがフォルダーに、またはフォルダーがファイルに変換されていません。

ドキュメントには、他のプロセスが属性を変更している可能性があり、属性を同期するためのロックメカニズムが遅延して書き込まれているため、「最新ではない可能性があります」と記載されています。アプリケーションが完全に最新の情報を必要とする場合は、情報が最新であることを保証する ...ByHandle を取得します。

于 2013-03-18T03:13:59.220 に答える
2

これは、すべてのステータス レポート機能が機能する方法です。せいぜい、関数を呼び出したときと関数が返されたときの間の未定義のポイントでステータスを報告するだけです。ただし、データが後で有効であることを保証するために「世界を凍結」するわけではありません。

ドキュメントでは、すべての関数についてこれを指摘するのではなく、通常、これが考慮されていない場合に深刻な問題、特にセキュリティの問題につながる傾向がある関数についてのみ言及します。

ファイルを開いてそのハンドルを取得すると、そのハンドルを使用するすべての操作が同じ基になるファイルに対して行われることが保証されます。しかし、名前で操作を実行する場合、そのような保証はありません。ファイルは、作成、削除、および名前変更できます。そのため、後で同じ名前が同じファイルを参照することはありません。

于 2013-03-18T03:24:42.683 に答える
1

dwFileAttributesファイルとフォルダーの違いを見分けることに関しては、信頼できないものではありません。このメモは、ファイル システムによって更新のためにキャッシュされる可能性のある情報 (変更された/アクセスされたタイムスタンプなど) を参照していると思いますが、アイテムがファイルであるかフォルダーであるかは変更されるものではありません。

于 2013-03-18T03:11:58.043 に答える