Failed to use FindFirstFileW and FindNextFileW

[hainingwu]

Hello,

I try to find all the files under a directory using FindFirstFileW and
FindNextFileW. All the filenames are encoded in UTF-8 originally, so I
convert them to UTF-16 in order to open UNICODE filenames on WIndows.
For example, I use FindFirstFileW in this way:

WIN32_FIND_DATA wfdFindData;
HANDLE hDirHandle;

hDirHandle = FindFirstFileW(utf8_to_utf16(DirectoryName),
&wfdFindData);

"DirectoryName" is a char string and contains the UTF-8 directory name
(I only put the directory name under my current directory, not the
full file path). "utf8_to_utf16" is my own function for the conversion
between UTF-8 and UTF-16. It accepts a UTF-8 string and returns a
wchar_t string with the converted UTF-16 contents. However, the above
code doesn't work at all. It seems that FindFirstFileW can't even find
the correct directory. I cannot figure out the reason.

Hai-Ning

[Norman Bullen]

Do you have UNICODE defined for this compilation? If so, you don't
really need to explicitly call FindFirstFileW(). FindFirstFile is a
define that expands to FindFirstFileW. But if you haven't defined
UNICODE, you're getting the wrong declaration of the structure that you
pass to FindFirstFileW(). Both WIN32_FIND_DATAA and WIN32_FIND_DATAW are
declared in WinBase.h and WIN32_FIND_DATA expands to WIN32_FIND_DATAW if
you haven't defined UNICODE.

How does your function utf8_to_utf16() return the result string
containing UTF-16 characters? I hope you're not returning a pointer to
an automatic variable in the function or a pointer to dynamically
allocated memory.

--
Norm

To reply, change domain to an adult feline.

[Dean Earley]

Try an absolute path.
FindFirstfile* is relative to the working path, not your EXEs path.

--
Dean Earley (dean....@icode.co.uk)
i-Catcher Development Team

iCode Systems

[Ulrich Eckhardt]

hainingwu wrote:
> WIN32_FIND_DATA wfdFindData;
> HANDLE hDirHandle;
>
> hDirHandle = FindFirstFileW(utf8_to_utf16(DirectoryName),
> &wfdFindData);

Two things here to check:
1. Does WIN32_FIND_DATA contain a byte-counter variable? If yes, you must
set it to the size of the structure so the system knows which version it
has.
2. I believe there are WIN32_FIND_DATAA and WIN32_FIND_DATAW structures, but
I'm not sure there either. Of course you would need the latter.

> "DirectoryName" is a char string and contains the UTF-8 directory name
> (I only put the directory name under my current directory, not the
> full file path). "utf8_to_utf16" is my own function for the conversion
> between UTF-8 and UTF-16. It accepts a UTF-8 string and returns a
> wchar_t string with the converted UTF-16 contents. However, the above
> code doesn't work at all. It seems that FindFirstFileW can't even find
> the correct directory.

I wonder what utf8_to_utf16() returns. The reason is that if it returns a
wchar_t*, the storage it points to is either local to the function and then
your code invokes undefined behaviour by still accessing it or it is e.g.
std::wstring but that doesn't work as parameter to FFFW(), which wants
a 'wchar_t const*' here.

> I cannot figure out the reason.

Just a few suggestions:
1. There are two things involved here, one is FFF() and the other
utf8_to_utf16(). Eliminate one of them, e.g. directly feed L"C:\\" to
FFFW(). If it works now, the other one was broken. ;)
2. Most functions signal success/failure via their returnvalue and some more
info in case of failure can be retrieved via GetLastError(). There is an
error-lookup tool included with some IDEs that helps you to map the number
to a text, otherwise the FormatString() function does the same.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932