Странная вещь в функциональности перечисления файловой системы .NET 4.0 - PullRequest
16 голосов
/ 18 апреля 2010

Я только что прочитал страницу «Что нового .NET Framework 4.0» . У меня проблемы с пониманием последнего абзаца:

Для удаления открытых дескрипторов перечисленных каталогов или файлов

  1. Создать пользовательский метод (или функцию в Visual Basic), чтобы содержать Ваш код перечисления.

  2. Примените атрибут MethodImplAttribute с параметром NoInlining к новому методу. Например:

    [MethodImplAttribute(MethodImplOptions.NoInlining)] Private void Enumerate()

  3. Включите следующие вызовы методов, которые будут выполняться после вашего перечисления код:

      * The GC.Collect() method (no parameters).
      * The GC.WaitForPendingFinalizers() method.
    

Почему атрибут NoInlining? Какой вред будет здесь делать?

Зачем вызывать сборщик мусора вручную, почему бы не сделать так, чтобы перечислитель вообще реализовывал IDisposable? Я подозреваю, что они используют API-интерфейсы FindFirstFile () / FindNextFile () для реализации, поэтому FindClose () должен вызываться в любом случае, если перечисление выполнено.

EDIT:

У кого-нибудь есть идея, почему в статье предлагается атрибут NoInlining?

1 Ответ

4 голосов
/ 19 апреля 2010

Довольно странно. Итератор правильно реализует IDisposable, он вызывает FindClose (). Параметры AllDirectories могут стать источником проблем, поскольку FindFileFirst / Next позволяет выполнять итерации только одного каталога. Но я вижу, что итератор делает правильные вещи, он сохраняет открытой только один дескриптор при итерации структуры каталогов.

В статье MSDN конкретно упоминается "если есть открытый дескриптор, который остается в одном из перечисленных каталогов или файлов". FindFileFirst / Next не оставит дескриптор открытым. Но небрежный пользовательский код, который читает файлы при перечислении, делает. «Операция удаления файла или каталога» тоже актуальна, я думаю, что поведение изменилось в Vista. DeleteFile () может быть успешным, но файл фактически не исчезнет, ​​пока все дескрипторы файла не будут закрыты.

Нам нужен кто-то для добровольной работы, а , а не для реализации этого кода в XP. Я думаю, мы скоро найдем кого-нибудь :) 1007 *

...