Можно ли объяснить этот причудливый катастрофический отказ во времени выполнения.NET?

Вы можете попробовать изучить код для System.IO.Path.GetFiles () с .NET Reflector . На первый взгляд, очевидно, что он вызывает только String.Substring () , чтобы разделить что-то с конца пути и добавить обратно ближе к концу метода. Он проверяет Path.DirectorySeparatorChar (обратная косая черта, '\' ) и Path.AltDirectorySeparatorChar (косая черта, '/' ) на определить индекс и длину подстроки.

Я предполагаю, что недопустимые имена файлов или папок в Юникоде сбивают с толку метод.

Угадайте ... есть ли имена файлов, передаваемых в качестве аргументов, длиннее 256 символов? Стандартные функции System.IO платформы .Net не могут обрабатывать файлы с более длинными именами.

Начиная с версии 3.0, оператор печати должен быть записан как функция ...

ваш

print (b, end = '')

становится

print ("end =", b)

Надеюсь, что это поможет, и удачи! Сообщите нам, какое решение вы нашли, оно наверняка окажется интересным.

Возможно, вы могли бы предоставить некоторые сведения о клиенте, у которого возникла проблема. Вещи как: 1. Название и версия ОС. 2. Язык ОС 3. Версия .Net, на которую вы нацеливаетесь, по сравнению с версией .Net, которую использует клиент.

В пути к каталогу могут быть символы Юникода, из-за которых длина строки может быть меньше одной или нескольких.

Другое примечание: текст исключения предполагает, что ваша программа была написана на управляемом C ++. Вы не вмешиваетесь в какие-либо неуправляемые манипуляции со строками?

Я мог бы предложить, если вы можете, изменить диагностику, чтобы фиксировать фактическую переменную пути, которая вызывает ошибку. Возможное правдоподобное объяснение: http://support.microsoft.com/kb/943804/

Возможно, это как-то связано с обфускатором. И обфукатор все портит. Попробуйте запустить код без обфускатора. И опубликуйте свои результаты.

редактировать: Вы можете воспроизвести аварию?

Первым и единственным вопросом должен был быть: «Вы запустили ChkDsk?»

Не уверен, что это связано, но я использую GetFiles в Visual C ++, он вылетал при перечислении содержимого C :, оказалось, что у меня была папка с испорченными разрешениями из предыдущего установить. Я вернул папку моему текущему пользователю, и он устранил сбой.

Исходя из источника и ваших комментариев, я подозреваю, что путь UNC вызывает проблемы с возможным разрешением безопасности или поделиться проблемой разрешения. Например, если пользователь отключил создание имен файлов 8.3, у вас определенно возникнут проблемы с UNC-путями, потому что из-за этого поставщик сети не сможет получить правильные имена файлов в Windows 2000 и Windows XP. (Я забыл, в каких пакетах обновления была исправлена ​​эта ошибка.)

Ниже приводится важный исходный код.

    String tempStr = Path.InternalCombine(fullPath, searchPattern);

    // If path ends in a trailing slash (\), append a * or we'll
    // get a "Cannot find the file specified" exception
    char lastChar = tempStr[tempStr.Length-1];
    if (lastChar == Path.DirectorySeparatorChar || lastChar == Path.AltDirectorySeparatorChar || lastChar == Path.VolumeSeparatorChar) 
        tempStr = tempStr + '*';

    fullPath = Path.GetDirectoryName(tempStr); 
    BCLDebug.Assert((fullPath != null),"fullpath can't be null!");

    String searchCriteria;
    bool trailingSlash = false;
    bool trailingSlashUserPath = false;

    lastChar = fullPath[fullPath.Length-1];
    trailingSlash = (lastChar == Path.DirectorySeparatorChar) || (lastChar == Path.AltDirectorySeparatorChar); 

    if (trailingSlash) {
        // Can happen if the path is C:\temp, in which case GetDirectoryName would return C:\ 
        searchCriteria = tempStr.Substring(fullPath.Length);
    }
    else
        searchCriteria = tempStr.Substring(fullPath.Length + 1); 

Есть ли возможность быстро запрограммировать консольное приложение и запустить его в режиме отладки. Обычно перебирают весь файловый каталог с помощью метода GetFiles. Может быть, что-то ударится, и вы сможете быстро найти проблемный файл?