Доброго времени суток! Получил лабу- вывести список всех удалённых файлов из заданного каталога и подкаталогов. Посколько WinAPI ещё не изучал, да и предмет требует реализации под DOS, бьюсь со следующим кодом-


по теории я понял, что нужно ловить из первого байта поля ffb.ff_name код E5h, который и означает, что файл удалён. только проблема в том, что с написанным условием в тело IF'а программа не заходит. вот и прошу совета опытных в этой среде людей- что именно я делаю не так?)
Зараннее благодарен!

имхо это преступление заставлять учить студентов программированию под DOS, где предполагается применять потом эти знания?

Это сообщение отредактировал(а) triclosan - 20.6.2011, 22:32

так лови из первого:

попробовал- по прежнему это условие игнорируется... проверял кстати следующим образом-  выводил список всех *.txt-шников в каталоге, потом удалял один из них и ставил это условие... результата никакого.

у printf есть фича %x, сделай так

не надо

Это сообщение отредактировал(а) triclosan - 20.6.2011, 22:52

почему?

я так понял что новый printf должен будет выдавать первый байт для всех txt-шников? я вставил его и получил только одно значение, значит что у меня проверлся только один файл? 

fish9370, поскольку язык Си растет их Юникс-мира, в текстовом режиме принято конец строки обозначать юниксоидным символов \n - при этом в *nix системах он не меняется, а в этих ваших ДОСах превращается в \r\n

Это сообщение отредактировал(а) triclosan - 20.6.2011, 23:03

IF SUCKS печатает?

Добавлено через 1 минуту и 30 секунд


никогда такого не слышал, где это написанно?

предыдущая инфа была не совсем верной- вообщем прога адекватно ловит все файлы и выводит их коды, только после удаление ничего не происходит и просто вместо 6 кодов (по количеству файлов) выводит 5 и 5 раз сообщение IF SUCKS. попробовал уже даже в findfirst завести весь список известных аттрибутов- не помогло... может есть альтернатива этому методу поиска удалённого файла?

да, есть.. только он тебе не понравится.. нужно считывать первый сектор диска (MBR), определять где находится системный раздел, находить таблицу распрределения файлов (FAT, кстати мы имеем дело с FAT32?), пробегаться по ее каталогу и делать тоже самое..


если у тебя есть ДОС, то найди проду diskedit.. с помощью нее можно шастать по диску, и дебажить..

все это у меня лишь воспаминания, десятилетней давности..

ха-ха-ха..   

порылся в исходниках findfirst и вот что я нашел:



- что не удивительно, это же пользовательская функция..

другими словами он не выдает удаленные файлы.. нужно искать другой метод.. либо тупо переписать функции поиска.. время у нас есть? 

Это сообщение отредактировал(а) fish9370 - 21.6.2011, 00:18

Никакие стандартные функции поиска (включая и findfirst) не будут возвращать записи для удаленных файлов (и это сделано уже на уровне ОС, а не в run-time библиотеке)

Так что только напрямую потрошить диск (в DOS), или открывать директорию на чтение (CreateFile с FLAG_BACKUP_SEMANTIC - в Win) и читать. И то и другое требует недюжинных познаний во внутренних структурах файловой системы   

думаю топик можно закрывать,всем спасибо за помощь) буду насиловать FAT)