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

Ещё смущает "PrintStringByAddr eax"
Также винда иногда глючит на некоторых функциях, если ESP перед вызовом функции не кратен 4 (поэтому всякие PUSH/POP AX лучше заменить на PUSH/POP EAX)

 

Это исключение возникло при недоступном стеке, либо вы исчерпали его, последнее маловероятно.

 

Не думаю что глючит функция. Просто работает она так. В msdn пишут что как функция вернёт данные - фиг его знает. Значит результат работы зависит от многих факторов (но нам любезно о них не сообщают).
S_Alex
Вы открывали найденые файлы?
Атрибуты не меняли?

 

Не нашел такого в мсдн

 

TSS
Странно, а я сразу нашёл
The order in which this function returns the file names is dependent on the file system type. With the NTFS file system and CDFS file systems, the names are usually returned in alphabetical order. With FAT file systems, the names are usually returned in the order the files were written to the disk, which may or may not be in alphabetical order. However, as stated previously, these behaviors are not guaranteed.

 

Кстати, я поэтому и просил запустить "глючную" программу под FAT.

 

Тут речь же о порядке найденных файлов всего лишь Падать то как у S_Alex все равно не должно, имхо код его кривой просто.

 

TSS
Выходит и у меня код глючный был с ReadDirectoryChangesW
Без обращения к файлам всё было хорошо, а вот если открыл файл - теже проблемы что и у S_Alex.

 

MirrorBlack
Не видел твой код с ReadDirectoryChangesW к сожалению, поэтому не могу сказать глючный он или нет

 

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

 

Кстати, по поводу IO_STATUS_BLOCK - его, наверное, лучше всегда проверять, так, на всякий случай, но вообще-то это нормальная ситуация - когда функция возвращает success и какую-нибудь ошибку в статусблоке? Этот блок вообще был придуман для того, чтобы сообщать о результатах асинхронных операций, но при этом сама функция должна возвращать что-нить вроде status pending, разве не так? (поле information, естественно, пригодилось и для синхронных операций тоже)

 

да, и топикстартеру - по-хорошему, после false от findnextfile следует проверить причину getlasterror'ом

 

Наконец под вечер получил свой ноут, и решил экспиремент провесть (на КПК не получалось ).
Написал программу создающую 100000 файлов. Работает так:
1) Создаются 100000 файлов, считаются успешно созданные
2) С помощью FindXXXFile подсчитывается их кол-во
3) То-же что пункт 2 + запись в каждый файл, считаются успешно открытые
А дальше как у Филатова:
Как ни мучалась Яга, а не вышло не фига.
Не удалось отловить ошибку. Три часа коту под хвост (9 попыток словить приход).

 

MirrorBlack
Да просто все ошибки у таких api были давно найдены