Непонятки с FindFirstFile,FindNextFile?

Всем читающим этот "?" Доброго всем времени суток.

Есть код:

Code (Text):

1.     invoke  MessageBox,NULL,ADDR T_Buf, lpSaveFolder,MB_OK
2.     invoke  FindFirstFile,ADDR T_Buf,ADDR wfd       ; Ищем файлы
3.     inc     eax                     ; Если ничего не нашли - выходим
4. .if !ZERO?
5.     dec     eax                     ; Иначе, сохраним
6.     mov     [hSrch],    eax         ; хэндл поиска
7.     .while  eax
8.         ;< покажим что нашли
9.         lea     eax,     [wfd.cFileName]
10.         PrintStringByAddr eax
11.         ;> 
12.         invoke FindNextFile,[hSrch],ADDR wfd            ; Ищем следующий файл
13.     .endw
14.     ; Если ничего не нашли
15.     invoke FindClose,[hSrch]                ; Закрываем хэндл поиска
16. .endif

Находит все файлы в указанной папке.
Но если убрать

Code (Text):

1.  invoke MessageBox,NULL,ADDR T_Buf, lpSaveFolder,MB_OK

или заменить на

Code (Text):

1.  invoke MessageBox,NULL,ADDR T_Buf, NULL,MB_OK

Отказывается работать, выводит только часть файлов.
T_Buf, wfd, hSrch - локальные переменные.
Из какой оперы этот прикол? Подскажите.

 

S_Alex
Было когдато такое, ставь задержку.

 

Clerk
Шаман однако!

Code (Text):

1.         invoke  Sleep,100

Помогло. СПСБ.
Правда тормоза ...

 

В поток вынеси

 

JCronos
Не верно. Связано с асинхронным чтением директори в апи, следует реализовать самостоятельно посредством натива.

 

А в чем, собственно, проблема с findnextfile? Хотите сказать, что функция настолько криво написана, что может с разу на раз пропускать некоторые файлы? oO

 

Nouzui
Это факт, я както писал поиск ресурсов с иконками во всех файлах, так эта апи кучу файлов пропускала.

 

Clerk
Т.е. "глюк" возникает если во время поиска обращаться на чтение/запись к найденому файлу?

 

Clerk, ни разу не замечал, чтобы тотал/проводник вот так "пропускали" файлы.
может, есть какие-то конкретные причины? Ось, FS, характер поиска, действия, предшевствующие findfirst и между вызовами findnext.. ?

 

MirrorBlack
Наверно изза того, что в FindFirstFile() не полностью выполняется проверка результата для сервиса NtQueryDirectoryFile получающего список файлов в директории, зотя может и флажки при открытии файлов тоже являются причиной..

 

Clerk
Я вспомнил подобную фигню с ReadDirectoryChangesW.
Лечилось sleep.
Вот я и думаю, может работать с предпоследним дискриптором?

 

IO_STATUS_BLOCK чекать наверно.

 

Clerk
Надо автору провести эксперимент - запустить под FAT.
Если глюк исчезнет - флажки всему виной.

 

Епт, первый раз слышу чтоб FindXxxFile так глючила) Никогда раньше не встречал.
Быть может все-таки у тебя ошибка?

 

Great
Какая есчо ошибка у меня может быть

 

Может FindFileNext попробовать проверять на (ноль) или на (ERROR_NO_MORE_FILES = 18) ?
Можно ещё попробовать обнулить структуру (wfd) перед вызовом FindFileFirst.
хотя вряд ли это делу поможет...

 

slavanap
Не наверно проще будет нтстатус проверить, так что лучше самому написать.

 

Clerk

5+
Не ошибается тот - кто ничего не делает

 

Спасибо за поддержку!
На 2000 всё прошло без всяких глюков, а на работе под XP SP2, то работает, то нет. Функция FindNextFile просто вылетает со всей прогой, ни сообщений обо ошибке ни ни. Просто "ХЛОП" и нет проги. Скорее всего глючно написанная функция FindNextFile. Два года назад, уже 3, юзал ее в потоке на этой же машине, проблем не было. Прога делала список файлов со всех жестких дисков. Работатала.
Может всё таки мне систему переустановить, 3 год как стоит.

 

Скорее всего баг в коде(99%), а не в FindNextFile.