FindFirstFile wildcard bug

[nocturnozor]

Hi,

While I was testing simple IO functions, I had a curious behavior for the
FindFirstFile function that is not referenced as a bug into the MSDN doc. So
be careful if, like me, you use this function under W2K. I didn't check that
the problem also occurs under 9x, Me, NT, XP... but I would't be surprised to
have the same behavior.

I was using it to retrieve all the files with a given extension. I called it
with :
HANDLE hFind = FindFirstFile("*.cpp", &wfd);
The problem is that such a call retrieves also files like "*.cpp2",
"*.cpp_", "*.cppcpp" and so on. It seems to be a bug since the problem occurs
only with 3 characters file extensions. If I try the following call :
HANDLE hFind = FindFirstFile("*.h", &wfd);
it works fine and I have only the .h files, not the .hpp files, for example.

So it's necessary to make an additionnal checking on the name ot the files
returned by FindFirstFile/FindNextFile to remove the unmatching files.

Regards
nono

[qfel]

Yeah, undocumented behaviour; It's mentionet int... .NET framework SDK in
Directory::GetFiles(string,string) documentation:
The matching behavior of searchPattern when the extension is exactly three
characters long is different from when the extension is more than three
characters long. A searchPattern of exactly three characters returns files
having an extension of three or more characters. A searchPattern of one,
two, or more than three characters returns only files having extensions of
exactly that length.
The following list shows the behavior of different lengths for the
searchPattern parameter:
"*.abc" returns files having an extension of .abc, .abcd, .abcde, .abcdef,
and so on.
"*.abcd" returns only files having an extension of .abcd.
"*.abcde" returns only files having an extension of .abcde.
"*.abcdef" returns only files having an extension of .abcdef.

[Doron Holan [MS]]

you are hitting 8.3 filename generation. open a cmd window and run a dir /x
* in the directory where you are running FindFirstFile and think this bug
is. I would guess that you *.cppcpp files have a *.cpp extension in their
8.3 filename.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"nocturnozor" <noctu...@discussions.microsoft.com> wrote in message
news:78B1E753-26E1-49E1...@microsoft.com...

[nocturnozor]

I'm sure that my problem, like all problems of the world, can find an
explanation... the 8.3 format why not, but when working under W2K on a NTFS
drive this behaviour has no sense.
I was lucky to see this result, that is a problem for me, and I bet that
this is a potential bug source for the most part of the file browsing
functions based on FindFirstFile, so to my mind it would be good to include
some information about that into the MSDN documentation... elsewhere than
into the .NET Framework SDK (thanks qfel).
Well, even if I didn't post my message to have feedback but just to warn
other developpers, Thanks Doron for your answer.

nono

[Gary Chanson]

"nocturnozor" <noctu...@discussions.microsoft.com> wrote in message
news:78B1E753-26E1-49E1...@microsoft.com...

This is not a bug . It is by design. It was a kludge put in to support
old programs which were not designed to handle long file extensions.

--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org

[qfel]

> This is not a bug . It is by design. It was a kludge put in to
support
> old programs which were not designed to handle long file extensions.

Then it's incompatible with new programs because it works not the way they
expect it to work.

[Gary Chanson]

"qfel" <RemIt...@aster.pl> wrote in message
news:cg2q4p$26rn$1...@mamut.aster.pl...

They should expect it. It's been this way since the introduction of
long file names.

[qfel]

Then why not everybody know it after reading proper documentation
(Find*File)?

[roman ziak]

Gary Chanson wrote:

> "qfel" <RemIt...@aster.pl> wrote in message
> news:cg2q4p$26rn$1...@mamut.aster.pl...
>
>>> This is not a bug . It is by design. It was a kludge put in to
>>
>>support

Thanks nocturnozor, this is very useful information.

I agree with qfel that this behaviour is a bug especially if it is not
documented.

If the application calls FindFirstFile from KERNEL32.DLL, this app has
been written as 32-bit; As far as I remember long filenames were
introduced in MS OSes in Win95 i.e. together with Win32.

The 8.3 compatibility code should have been implemented in INT21
emulation layer.

>>
>>>old programs which were not designed to handle long file extensions.
>>
>>Then it's incompatible with new programs because it works not the way they
>>expect it to work.
>
>
> They should expect it. It's been this way since the introduction of
> long file names.
>

Gary, I am a long time Win32 programmer and I did not know that and
would not expect it; since I always use FindFirstFile("*", ...) and do
search elsewhere.

[Carl Daniel [VC++ MVP]]

nocturnozor wrote:
> Hi,
>
> While I was testing simple IO functions, I had a curious behavior for
> the FindFirstFile function that is not referenced as a bug into the
> MSDN doc. So be careful if, like me, you use this function under W2K.
> I didn't check that the problem also occurs under 9x, Me, NT, XP...
> but I would't be surprised to have the same behavior.

This is an obscure but known behavior. See for example

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&selm=OATgbJ3VDHA.1512%40TK2MSFTNGP11.phx.gbl

and the rest of the thread from that message.

I don't have time to check it at the moment, but I recall that if you give
it a path of \\?\full_path_to_directory\wildcard that the function will
behave like you want... but don't quote me on that without testing it first!

-cd