Путь к каталогу с учетом регистра в Windows

Question

Я рассмотрел вопросы / ответы, спрашивающие, чувствительны ли имена каталогов / файлов в среде Windows, а также те, которые обсуждают необходимость поиска с учетом регистра [обычно в Python, а не C], поэтому я думаю, что Я понимаю основные факты, но ни одна из публикаций не включает мою конкретную архитектуру приложения и проблему, с которой я сталкиваюсь при решении проблемы. Итак, позвольте мне кратко объяснить архитектуру приложения, о котором я говорю. Сердце приложения построено с использованием Adobe AIR. Да, это означает, что большая часть U / I включает инфраструктуру Flex, но проблема обработки файлов, с которой мне нужна помощь, не зависит от части приложения Flex U / I приложения. Поскольку я пытаюсь обработать очень большой список рекурсивных структур каталогов, я использую API-интерфейс RunTime низкого уровня C через механизм с хорошим поведением, который AIR обеспечивает в тех случаях, когда необходим доступ к собственной среде хоста.

Набор функций, которые я использую, это FindFileFirst, FindFileNext и FindClose. Если я пишу отдельную тестовую программу, она хорошо перечисляет каталоги, подкаталоги и файлы. Случай с каталогами и файлами отображается правильно - так же, как они правильно отображаются в проводнике Windows или с помощью команды dir.

Однако, если я запускаю точно такую ​​же функцию через интерфейс Adobe ANE, я получаю точно такой же вывод, за исключением того, что все имена каталогов будут сокращены до строчных.

Теперь я должен уточнить, что когда этот код выполняется как собственное расширение, он не передает данные обратно в AIR, он напрямую выводит результаты в файл, который полностью открывается и закрывается в мире CRT, поэтому мы не говорим о какой-либо путанице в коммуникации через передачу текстовых или байтовых массивов между двумя разными мирами.

Не запутывая этот форум множеством постороннего кода, я думаю, что всем, кто сможет мне помочь, помогут следующие фрагменты:

// This is where the output gets written.
FILE* textFile = _wfopen (L"Peek.txt", L"wt,ccs=UTF8");

WIN32_FIND_DATAW fdf;
HANDLE find = NULL;
wchar_t fullPath[2048];

// I am just showing the third argument as a literal to exemplify
// what, in reality is passed into the recursively-called function as
// a variable.
wsprintf (fullPath, L"\\\\?\\%ls\\*.*", L"F:\\");
hFind = FindFirstFile (fullPath, &fdf);

// After checking for success there appears a do..while loop
// inside which there is the expected check for the "." and ".."
// pseudo directories and a test of fdf.dwFileAttributes for
// file versus sub-directory.
// When the NextFile is a file a function is called to format
// the output in the textFile, like this:

fwprintf (textF, L"%ls\t%ls\t%2.2x\t%4d/%02d/%02d/%02d/%02d/%02d  \t%9ld.\n",
     parentPath, fdf.cFileName,
    (fdf.dwFileAttributes & 0x0f),
    st.wYear, st.wMonth, st.wDay,
    st.wHour, st.wMinute, st.wSecond,
    fSize);

На этом этапе parentPath будет объединенной строкой широких символов и остальные атрибуты файла будут отображаться следующих типов.

Итак, подведем итог: весь этот код отлично работает, если я просто напишу автономный тест. Однако, когда код выполняется как задача, вызываемая из Adobe ANE, имена всех частей подкаталога сокращаются до строчных. Я проверил каждую комбинацию атрибута типа файла - двоичный и текстовый, а также кодировку - UTF-8 и UTF-16LE, но независимо от того, какую конфигурацию я выбрал, результат остается тем же: автономный API доставляет строки с учетом регистра, выполняя в качестве задачи в DLL, вызываемой из AIR, тот же API доставляет только строчные буквы.

Answer 1

Во-первых, спасибо господам Огилви и Пассанту за полезные советы.

Во-вторых, я прошу прощения за то, что не знал этот протокол как очень редкий посетитель. Если я должен пометить любой ответ как полезный и, следовательно, правильный, пусть эти слова хотя бы отражают этот факт.

Я даю ответ, который был обнаружен с помощью приведенного выше совета.

A. Я обнаружил несколько инструментов, которые помогли мне разобраться с содержимым файлов .exe и .dll. Я должен добавить некоторые детали, которые не были частью первоначальной публикации: я специально использовал инструментальную цепочку mingw-w64 вместо Visual Studio для этой работы по разработке. Так что, как оказалось, и ldd, и dumpbin помогли мне понять, оставляют ли две слегка отличающиеся среды сборки разные зависимости.

B. Когда я увидел, что в одном из выходных данных содержалась ссылка на FindFirstFileExW, функцию, которую я когда-то пытался решить для решения проблемы, я подумал, что, возможно, нашел причину для других результатов. В данном случае это была просто красная селедка, и я не хочу тратить время на форуме из-за моего низкого уровня опыта и понимания, но кажется полезным отметить такую ​​методологию устранения неполадок в качестве возможной помощи другим .

С. так в чем была проблема? Действительно, в коде между автономной и ANE-интегрированной реализациями рекурсивного поиска по каталогу было небольшое различие. В случае использования ANE производства существует логика для применения уровня фильтрации к возвращаемым результатам. Фактическое приложение позволяет пользователю квалифицировать поиск дубликатов файлов путем опроса частей родительской строки в дополнение к самой строке имени файла.

В одном угловом условии фильтр может быть чувствителен к регистру или нечувствителен к регистру, и я использовал _wcslwr из-за ошибочного убеждения, что эта функция ведет себя хорошо, Unicode-совместимый способ, которым методы обработки строк предоставляются в AIR / Actionscript3. Я не заметил, что функция фактически выполняет замену исходной строки на место строкой, уменьшенной на строчные.

Ошибка пользователя, а не любое нежелательное связывание нестандартных функций ядра CRT с помощью совместимости Adobe Native Extension.