It doesn't work

[FrancescoItaly]

#include <iostream>
#include <string>
#include <Windows.h>

void printFile( HANDLE, WIN32_FIND_DATA );

int main()
{
	HANDLE indice;
	WIN32_FIND_DATA infoFile;
	
	indice = FindFirstFile( "*.*", &infoFile );

	printFile( indice, infoFile );

	system( "pause" );
	return 0;
}

void printFile( HANDLE index, WIN32_FIND_DATA fileInfo )
{
	std::string directory;

	// condizione per poter uscire dal ciclo
	if ( index == INVALID_HANDLE_VALUE )
		return;
	
	else
	{
		std::cout << fileInfo.cFileName << std::endl;
		
		// se è una directory 
		if ( GetFileAttributes( fileInfo.cFileName ) == FILE_ATTRIBUTE_DIRECTORY )
		{
			directory = fileInfo.cFileName;
			directory += "\\*.*";
			printFile( FindFirstFile( directory.c_str(), &fileInfo ), fileInfo );

		}

		// vado al prossimo file 
		if ( FindNextFile( index, &fileInfo ) )
			printFile( index, fileInfo );
	}
}

Why my source doesn't work?

[webJose]

Don't make us guess. Post the error you are getting. Explain what is it that doesn't work.

[andywestken]

FindFirstFile only returns the file or subdirectory name. To get recursion to work you need to pass the current full path to your recursive calls.

Also, the current directory (.) and parent directory (..) are both returned by FindFirstFile / FindNextFile, to you need to add logic so these are skipped.

Finally, I don't see any balancing calls to FindClose?

I would rework your function so it calls FindFirstFile then, if successful, FindNextFile (in a loop) and finally FindClose. Without recursion to start with

Once that works, add the recursion.

Andy

P.S. You don't need a separate call to GetFileAttributes; use the dwFileAttributes member of the find data struct.

[Disch]

Also, if you want to find all files, use "*", not "*.*"

"*.*" will not find files that don't have a . in the name (which is common with directories, but can also happen with regular files too. IE: "README")

[andywestken]

For Windows, *.* works fine. I use it all the time, and it has no problem finding the directories and extension-less files.

But I think it does make a difference in the Linux world (I'm not sure, as I don't visit it that often).

Andy

P.S. That is *.* will find README on Windows!

[Disch]

I can't test it now, but I have a really hard time believing you.

"README" clearly doesn't match the "*.*" format string so there's no reason why Windows should find it.

I'll test it when I get home.

EDIT:

You're right, it does show everything.

That's retarded. It really shouldn't. They must have made a special case for that.

[andywestken]

It's not a special case; it's the way DOS was and Windows is. The DOS FAT file system stores the file name and extension independently. The . is not itself stored.

When long file name support was added, this behaviour was maintained.

If I understand correctly, Linux does not understand what a file extension is. A file name with a dot in is just a file name with a dot in.

As Windows works out what to do with a file based on its extension, though its (naff or otherwise) file association mechanism, the extension is treated specially (not just as a bit of a file name).

Andy