» Функции FindFirstFile и FindNextFile

Привет всем !

Помогите разобраться как работают функции
FindFirstFile и FindNextFile в С++, а то пишу

Код:
LPWIN32_FIND_DATA finddata;

FindFirstFile("C:\1\*.rar", finddata);

А на чем пишешь: BC++ или VC++, или еще что?

Вот примерчик из MSDN, может пригодится:


Код:
WIN32_FIND_DATA FileData;
HANDLE hSearch;
DWORD dwAttrs;
char szDirPath[] = "c:\TEXTRO\";
char szNewPath[MAX_PATH];
char szHome[MAX_PATH];

BOOL fFinished = FALSE;

// Create a new directory.

if (!CreateDirectory(szDirPath, NULL))
{
ErrorHandler("Couldn't create new directory.");
}

// Start searching for .TXT files in the current directory.

hSearch = FindFirstFile("*.txt", &FileData);
if (hSearch == INVALID_HANDLE_VALUE)
{
ErrorHandler("No .TXT files found.");
}

// Copy each .TXT file to the new directory
// and change it to read only, if not already.

while (!fFinished)
{
lstrcpy(szNewPath, szDirPath);
lstrcat(szNewPath, FileData.cFileName);
if (CopyFile(FileData.cFileName, szNewPath, FALSE))
{
dwAttrs = GetFileAttributes(FileData.cFileName);
if (!(dwAttrs & FILE_ATTRIBUTE_READONLY))
{
SetFileAttributes(szNewPath,
dwAttrs | FILE_ATTRIBUTE_READONLY);
}
}
else
{
ErrorHandler("Couldn't copy file.");
}

if (!FindNextFile(hSearch, &FileData))
{
if (GetLastError() == ERROR_NO_MORE_FILES)
{
MessageBox(hwnd, "No more .TXT files.",
"Search completed.", MB_OK);
fFinished = TRUE;
}
else
{
ErrorHandler("Couldn't find next file.");
}
}
}

// Close the search handle.

if (!FindClose(hSearch))
{
ErrorHandler("Couldn't close search handle.");
}

NSentinel
Спасибо за помощь

Цитата:

А на чем пишешь: BC++ или VC++, или еще что?

Пишу я на BC++

Цитата:

В конце-концов можно пройтись по структурам файловой системы, используя прямой доступ к физическому диску

Это как Если можно, напиши поподробнее...

Цитата:

На каком уровне тебя интересует решение? Используя просто другие Win32 API функции или не используя вообще Win32. В общем, опредились, а я расскажу

Вообще было бы неплохо узнать рефлизыцию обоих вариантов...

Заранее благодарен

Не правильно:
-----------------
LPWIN32_FIND_DATA finddata;
FindFirstFile("C:\1\*.rar", finddata);

Правильно:
--------------
WIN32_FIND_DATA finddata;
FindFirstFile("C:\1\*.rar", &finddata);


А если кто хочет пройти структуру диска низким уровнем под Windows, то флаг в руки и электричку навстречу.

Т.е. и это тоже возможно, но под Windows 9X придется иметь дело с thunk-транслятором, хотя и это можно...

А под Windows 2000/XP граблями будет NTFS, точнее ее закодированные файлы. Там мало не покажется... Хотя, если нет закодированных файлов, можно попробовать.

Такими приколами занимаются программы восстановления, ремонта и бинарного редактирования, типа WinHex. Если будете этим заниматься, лучше всего выделить отдельный комп и постоянно делать backups.

P.S. Я за эти советы ответственности не несу, но рассказать как - могу.

react

Цитата:

Вообще было бы неплохо узнать рефлизыцию обоих вариантов...

А зачем тебе? Просто хочется знать: зачем такое может сейчас понадобиться?

Можно попользовать Win32 API SearchPath правда только для поиска конкретного файла, не для перечисления содержимого. Насколько знаю из файловых функций альтернативы FindFirst/FindNext нет. Кстати, чем же они тебе не подходят

Альтернативой Win32 является использование другого API винды, например Native API под NT или ты можешь написать свой драйвер для перечисления файлов, используя Kernel API и обращаться к нему за такой инфой Но, ИМХО кроме некоторых специфицеских случаев, это совершенно не надо

OldGopher

Цитата:

Не правильно:
-----------------
LPWIN32_FIND_DATA finddata;
FindFirstFile("C:\1\*.rar", finddata);

Правильно:
--------------
WIN32_FIND_DATA finddata;
FindFirstFile("C:\1\*.rar", &finddata);

Ну зачем же так категорично
react достаточно было выделить память и все бы заработало... Например, с помощью new (см. мой пост выше)



Цитата:

А если кто хочет пройти структуру диска низким уровнем под Windows, то флаг в руки и электричку навстречу.

Спасибо за добрые пожелания...


Цитата:

Т.е. и это тоже возможно, но под Windows 9X придется иметь дело с thunk-транслятором, хотя и это можно...

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

Если нужно пришлю пример работы под Win9x напрямую с диском. Писал когда-то по молодости


Цитата:

Такими приколами занимаются программы восстановления, ремонта и бинарного редактирования, типа WinHex. Если будете этим заниматься, лучше всего выделить отдельный комп и постоянно делать backups

Лучше наверное использовать VMWare. Создать машину, скопировать ее и держать резервной. Если винт на первой "накроется", то легко его восстановить просто скопировав файл виртуального диска.

Ну и немного тех. инфы...

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

WinNT предоставляет непосредственный доступ как к логическим дискам, так и к физическим. Для этого используется функция CreateFile, у которой в качестве имени используется либо "\.\PHYSICALDRIVE0", либо "\.\A:" для получения доступа к диску как к файлу. Затем используются стандартные функции для файлов: SetFilePointer, ReadFile, WriteFile и т.д. Кроме того, в WinNT работают функции IOCTL и FSCTL для устройств. Поподробнее об этом можно почитать в хелпе по Win32, например в MSDN, см. CreateFile, DeviceIoControl.

В Win9x все реализовано по-другому, и метод, применяемый в NT, не работает. Собственно, для демонстрации его я и написал программку, которую предложил выслать.
Если коротко: доступ к диску в Win95 можно получить, используя те же функции DOS и BIOS, что и в обычном случае, только вызывать их надо не напрямую (типа asm{ ... Int 0x13}), а используя для вызова VWin32.VxD.
Загрузить драйвер можно с помощью все той же функции CreateFile.
"Общение" с ним ведется с помощью функции DeviceIoControl. При этом функции передается структура со значениями регистров, и, в зависимости от требуемого действия, вызывается соответсвующая подфункция драйвера VxD.

Это один из вариантов доступа, и я не утверждаю что он лучший или даже просто хороший

Если коротко то это все Получив доступ к диску, дальше разбираем структуры файловой системы и готово

NSentinel
Дык весь базар-то и состоит в разборке файловой системы.

Если дело в FAT-структуре, тогда все просто. NTFS до 5-й версии - тоже просто.
А вот когда начались дела с Kerberos, тут уже стало не до шуток.

Даже весьма уважаемые дефрагментаторы от Execsoft, O&O, Symantec порой спотыкаются на закодированных другим юзером файлах. Из DOS их вообще никак не достать... Зато есть полезная вещь - bitmap диска.

Так что я вообще не советую лезть глубоко в NTFS-5+, а то можно лишних дров наломать...

OldGopher

Цитата:

Дык весь базар-то и состоит в разборке файловой системы

Я ж с тобою полностью согласен Без серьезных на то причин, как я уже говорил, лезь к диску руками, мягко говоря, не стоит

Мало того, что проблемы возникнут с реализацией поддержки EFS, так и у приложения будут серьезные проблемы при переносе на другую платформу... Да и мороки неоправдано много.

Как говорится, "Овчинка выделки не стоит" (с) Народ


Цитата:

Так что я вообще не советую лезть глубоко в NTFS-5+, а то можно лишних дров наломать...

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