Click to See Complete Forum and Search --> : FindFirstFile & FindNextFile return extra files?


bronzefury
June 11th, 2005, 11:53 AM
Hi,

I was wondering if anyone has encountered this problem. I'm using Win32 API calls FirstFile() and FindNextFile() to search for files on my computer. The problem is, both function calls seem to return extra files that aren't part of my search string. Has anyone else experienced the same problem?

I wrote a C/C++ console program that prompts for a Search String and a Search Path.

To recreate this problem, I enter "bc" as the search string (without the quotes) then enter the search path as "C:\" .. again, without the quotes but the backslash is required.

The program will start by gathering all directories and subdirectories that exist on the computer then search for files in each directory that contain the search string by passing C:\*bc* to FindFirstFile(). The program attaches the asterisks to the Search String.

FindFirstFile and FindNextFile returns many files that contain the letters "bc", "bC", "Bc", and "BC". The problem is, these function calls will also return a few files that don't contain the letter "bc","BC","bC", or "Bc".

I've attached the source code.

If you'd like to run this code to see what I'm jabbering about, just be aware that it generates a file called findfile.dat. I use this file as an aid to debugging and contains the list of all files found. For files where there is an incorrect match, I print BAD MATCH.... It flags a BAD MATCH for files that contain "BC","bC", or "Bc" so ignore those. But it will also flag a BAD MATCH for files that don't contain these letters and also indicate which function call found that file, either FindFirstFile() or FindNextFile().

bronzefury
June 13th, 2005, 03:35 PM
was wondering, has anyone tried running my code to see if this problem occurs?

thanks,

SuperKoko
June 13th, 2005, 04:05 PM
Ah ah ah, i think that i have found the solution:
If you have a FAT32 file system, FindFirstFile/FindNextFile search not only the matching long names, but also matching short names.
For example this file name:
"bab cool"
has this short name:
"BABCOOL"
Spaces are removed in short names!
Note also that all the Windows file system is not case-sensitive.

With short names, it is funny to search all files containing the number 1, on the hard drive, and to see that there are many, many more than it should, because of many short names terminated with ~1.

You should verify matching with short name, and with long name, and perform non-case-sensitive match.

bronzefury
June 13th, 2005, 09:37 PM
Hi,

I'm using NTFS

Here's an example of a file that shows up with my search path is "C:\" and search string is "bc".

BAD MATCH FindFirstFile - Extra File::1072 c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg006.html
c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg006.html
BAD MATCH FindNextFile - Extra File::1072 c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg016.html
c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg016.html
BAD MATCH FindNextFile - Extra File::1072 c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg026.html
c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg026.html
BAD MATCH FindNextFile - Extra File::1072 c:\Program_Files\Dev-Cpp\Docs\Allegro\alleg036.html

Notice that there is no "bc" anywhere in the file name.

Please try running. This bug has got me pulling hairs..

Andreas Masur
June 14th, 2005, 01:57 AM
I didn't look at your code, however, you might want to take a look at the following FAQ (http://www.codeguru.com/forum/showthread.php?t=312461)...

SuperKoko
June 14th, 2005, 02:55 AM
Please try running. This bug has got me pulling hairs..
I already ran it.
And, with my Computer (FAT32, Windows 98), it works correctly.
I am really sorry, it looks like a bug with NTFS.

Andreas Masur
June 14th, 2005, 05:59 AM
I am really sorry, it looks like a bug with NTFS.
I really would doubt that....I never experienced any problems while iterating file names...disregarding what file system... ;)