FindFirstFile\ FindNextFile

Нужно получить содержимое папки (включая все подпапки и файлы в них).

Вопрос: можно ли это сделать быстрее и проще чем использовать FindFirstFile, FindNextFile

И ещё при использовании FindFirstFile\ FindNextFile с путём для поиска ... *.* FindFirstFile

находит точку а FindNextFile – две, следующие FindNextFile находят нормальные файлы, так

должно быть ?



517308021__1.rar

 

ИМХО нет.

А то, что находится точка - так это текущий каталог.

 

ответ:

1) быстрее — да, под NT NtQueryDirectoryFile.

2) проще — в общем случае нет, посмотри в библиотеке си, может там проще.

3) "точка" и "две" - это ссылки на текущий и родительский каталоги, они заложены в сами ФС. Другое дело, что они не всегда нужны тому, кто запрашивает список файлов, но тут ничего не поделаешь.

 

А какой смысл искать, какая функция быстрее, если скорость ограничена скоростью вращения винта, а не тем, какие функции задействованы. Из времени, которое ф-ция тратит на добывание имени, минимум 90% уходит на то, чтобы крутить винт.

Точки можно просто игнорировать.

 

2 noonv & IceStudent

Ну про точки примерно так и думал.

2 cresta

Поискать альтернативу стоит хотяб потому что данный вариант может вызвать переполнение стека.

О существовании NtQueryDirectoryFile знаю, но не знаю как использовать, если у кого есть что почитать то поделитесь плиз !

 

Sonic_

> Поискать альтернативу стоит хотяб потому что данный вариант может вызвать переполнение стека

Да и большое число открытых хэндлов то же не есть гуд. Альтернатива - не использовать рекурсивный вызов get_folder_content. При каждом проходе FindFirst\FindNext нужно просто помещать имена папок в список (очередь), а по окончании поиска в текущей папке переходить к поиску в подпапках.

 

Sonic_



Переполнение стека вызывает любая процедура, многократно вызывающая сама себя, и имеющая некоторое кол-во входных параметров, передаваемых через стек. FindFirstFile\FindNextFile сама себя не вызвает, и переполнения вызвать не может.

 

Вопрос: NtQueryDirectoryFile требует хендл, чем его получить (какой функцией) ?

 

Sonic_

чем его получить

Например, NtOpenFile.



Использование NtQueryDirectoryFile см. find.c.



Без испльзования NtQueryDirectoryFile см. Does anyone know how to get a directory listing using NtQueryDirectoryFile()?

 

Спасибо q_q





122787304__ViewFolder_final.rar

 

Памяти выделяется мало. При большом кол-ве файлов падает программа.

 

Исправим. Как решение, можно предложить сделать File

Mapping и писать туда.

 

Зачем? Будет ещё тормоз. Ты же определяешь длину строки с именем найденного файла, вот и заведи переменную, в которой суммируй длину всех имен. Когда достигнет выделенного предела, запрашиваешь новый кусок памяти в дополнение к первоначально выделенному.

Только надо будет GlobalAlloc заменить на VirtualAlloc, чтобы новый кусок выделялся сразу за заполненным, без разрыва.

 

Sonic_

можно ли это сделать ... проще

Да.

dir [диск:][путь][имя_файла] /s /b | sort > FolderContent.txt

 

q_q

Мне кажется, что FindFirstFile\FindNextFile лучше



cresta



GlobalAlloc+GlobalReAlloc вроде тоже можно ?

 

Sonic_

Критерии оценки лучшести?

 

Sonic_

> "GlobalAlloc+GlobalReAlloc вроде тоже можно ?"

Можно, но не нужно Эту тему уже сотни раз обсуждали. Во-первых, GlobalXXX устаревшие функции, оставленные для обратной совместимости с 16-бит windows, работают они как и HeapXXX через RtlXXXHeap, но с дополнительными наворотами и поэтому медленнее (см.msdn). Во-вторых, блоки более 512К хип-менеджер по любому выделяет через VirtualAlloc, но адресов при этом резерервирует столько сколько запросили (округляет вверх до 64К). Поэтому при GlobalRealloc приходится резервировать новый блок памяти и копировать туда данные (в лучшем случае путем трансляции выделенных страниц по новым адресам, в худшем путем копирования данных - как на самом деле не знаю). Поэтому в твоей задачке лучше напрямую использовать VirtualAlloc сразу резервируя "XXL" мегабайт, тогда в случае нехватки первоначально выделенной (commit) памяти можно ее наращивать без разрывов и перелокаций.

 

2 q_q

FindFirstFile\FindNextFile возвращает доп. информ,а dir

сохранит всё в текстовом виде и всё, делай что хочешь.

Да и чем оно проще, лучше, быстрей ? Тут ведь задача не

сохранить всё в файл.



2 leo

Спасибо, попробуем

 

Sonic_

Тут ведь задача не сохранить всё в файл.

Imho ViewFolder_final только и делает, что пытается сохранить найденные имена в файл. Разве не так?



и чем оно проще

Тем, что достаточно вызвать CreateProcess.

 

"Imho ViewFolder_final только и делает, что пытается сохранить найденные имена в файл. Разве не так?"



Открой и посмотри, что и как !