Zapis co pliku txt (WinAPI)

Witam,
Chcę napisać prostą wyszukiwarkę plików w winapi. Na razie ma być to winapi ale bez graficznych okienek, czyli po prostu w konsoli. Ma on wyszukiwać pliki po rozszerzeniach. Algorytm przeszukiwania dysku już mam jednak chciałbym również aby rezultat pracy (ścieżki do plików) był zapisywany w pliku tekstowym. No i za chiny nie mogę zmusić programiku żeby to robił ;) W konsoli normalnie wypisuje ścieżki, ale nie wiedzieć czemu nie działa ani:

FILE *plik;
fopen("plik.txt", "a");
fprintf(plik, sciezka);
fclose(plik);

ani nawet:

ofstream plik;
plik.open("plik.txt", ios::app);
plik << sciezka;
plik.close();

Czy w winapi trzeba jakoś inaczej podchodzić do sprawy zapisu do pliku? Jak już wcześniej wspomniałem używając :`cout<<sciezka; ` normalnie wypluwa mi ścieżkę do pliku w konsoli. Z góry dzięki za pomoc. Pozdro

Nie znam się za bardzo na winapi, ale...

Mariolos napisał(a)

używając :cout<<sciezka; normalnie wypluwa mi ścieżkę do pliku w konsoli.

...czyli 'sciezka' jest typu std::string? Jeżeli tak, to masz odpowiedź czemu nie działa.

ech, ciągle nic... nawet gdy próbuje wypisać zwykłe "acb" to i tak nic się nie dzieje. Ale wrzuciłem tek kawałek kodu związany z tworzeniem i dopisywaniem do pliku do funkcji winmain i o dziwo zadziałał... tzn stworzył plik z "abc". Z tym, że to mnie nie ratuje gdyż potrzebuję zapisywać ścieżki do plików, a wyszukuję je w funkcji i nie chciałbym jej za bardzo przerabiać. Niżej wstawiam cały kod... może ktoś będzie wiedział co jest nie tak.

 
#include <iostream>
#include <stdlib.h>
#include <windows.h>
#include <fstream>
using namespace std;

void Szukaj(char *curdir)
{
    WIN32_FIND_DATA wfd;
    BOOL IsFile = TRUE;
    HANDLE hFile;
    char path[900];
    SetCurrentDirectory(curdir);
    hFile = FindFirstFile("*.*", &wfd);

    ofstream plik;
    plik.open("pliczek.txt", ios::app);

    while (IsFile)
    {
        char *sstr;
        GetFullPathName(wfd.cFileName, 899, path, NULL);
        if ((wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) && (wfd.cFileName[0] != '.'))
            Szukaj(path);
        if (!(wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) &&((sstr = strstr(path, ".txt"))))
        {
            cout << path << endl;
            plik<<"abc";  //w przeciwieństwie do maina nic nie wpisuje, a nawet nie tworzy pliku
        }
        IsFile = FindNextFile(hFile, &wfd);
    }
    plik.close();

    if (curdir[0] > 3)
        SetCurrentDirectory("..");
}


int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int nCmdShow)
{
    /*    // to działa i wpisuje do pliku "abc"
       ofstream plik;
       plik.open("pliczek.txt", ios::app);
       plik<<"abc";
       plik.close();
    */

    Szukaj("D:\\save");
    return 0;
}

Ogromne dzięki za pomoc :)
EDIT: Co do działania programu wszystko jest okej. Jednak zauważyłem (można było się domyślić ;) ), że przy przeszukiwaniu danej partycji program zwiększa użycie pamięci w nieskonczoność. U mnie doszło do 2,5 Gb i wyłączyłem. Plik tekstowy wyniósł prawie 100 Mb xD
Czy jest jakaś możliwość dynamicznego zwalniania pamięci programu, powiedzmy po osiągnięciu 200 Mb?

I tu jest problem z rekurencja, zauwaz, ze za kazdym razem gdy wywolywana jest funkcja Szukaj na stos odkladany jest prawie 1kB danych (char [900] + inne zmienne). Pamiec zostanie zwolniona dopiero po wyjsciu z funkcji. Teraz zalozmy, ze masz na woluminie C: 10 folderow, wolasz funckje, ona "zjada" 1kB i wola sama siebie 10 razy, masz juz 11kB zajete, teraz kazde z wywolan tych funkcji powiedzmy wola sie jeszcze 10x (10 kolejnych podfolderow w kazdym z 10 poprzednich), dochodzi Ci 100kB, lacznie masz juz wykorzystane 110kB pamieci a to dopiero 2 poziom ...
Musialbys przemyslec algorytm raz jeszcze. :)

Mariolos napisał(a)

[...] U mnie doszło do 2,5 Gb i wyłączyłem. [...]

2,5 GB stosu? coś mi się nie chce wierzyć, dawno powinno się wysypać...

Mozna dodawac do listy na zewnatrz, wtedy mniej stos sie dobija.

Ja tu widze wieksze zlo. Ktos nie zamyka pliku i wola szukaj co przy zlych wiatrach moze bardzo zuzywac uchwyty do otwartych plikow.

Te problemy jeszcze bardziej by wyszly gdyby chciec wykorzystac wielowatkowosc ...