FindFirstFile and wildcards.
Alex Blekhman
#include <windows.h>
#include <stdio.h>
#include <tchar.h>
int _tmain(void)
{
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
LPCTSTR szExt[] = { __TEXT("*.extn"), __TEXT("*.ext"),
__TEXT("*.ex"), __TEXT("*.e"), NULL };
hFind = FindFirstFile(szExt[1], &FindFileData);
if(INVALID_HANDLE_VALUE == hFind) {
_tprintf(__TEXT("No files found.\n"));
}
else
BOOL run = TRUE;
while(TRUE == run) {
_tprintf (__TEXT("%s\n"), FindFileData.cFileName);
run = FindNextFile(hFind, &FindFileData);
}
FindClose(hFind);
}
return 0;
}
Working directory contains files with extensions: .EXTNS .EXTN .EXT .EX .E
When I specify any extension except .EXT, files found correctly - only files
that match extension exactly are displayed. But when I specify .EXT then
displayed all files that match this extension and all files with extensions
.EXT* i.e. longer extensions.
Why this happens? Why only 3-char long extension wildcard produces such
results?
Thanks in advance
Alex
Chris Marriott
Alex Blekhman <tk...@yahoo.NOSPAM.com> wrote in message
news:a8615.24365$Vt5.1...@telenews.teleline.es...
> Working directory contains files with extensions: .EXTNS .EXTN .EXT .EX .E
>
> When I specify any extension except .EXT, files found correctly - only
files
> that match extension exactly are displayed. But when I specify .EXT then
> displayed all files that match this extension and all files with
extensions
> .EXT* i.e. longer extensions.
>
> Why this happens? Why only 3-char long extension wildcard produces such
> results?
The reason this happens is because the directory stores both "long" and
"short" filenames, and you're getting matches on both forms of the name. If
a file has an extension of ".EXTNS", then its short name will have an
extension of ".EXT", so the search for "*.EXT" is generating a match on
that.
You'll see exactly the same if you start a command prompt, and type the
command "dir *.ext".
Regards,
--
Chris
-----------------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com)
Visit our web site at http://www.skymap.com
Astronomy software written by astronomers, for astronomers
Alex Blekhman
news:960825896.664.1....@news.demon.co.uk...
>
> Alex Blekhman <tk...@yahoo.NOSPAM.com> wrote in message
> news:a8615.24365$Vt5.1...@telenews.teleline.es...
> > Working directory contains files with extensions: .EXTNS .EXTN .EXT .EX
.E
> >
> > When I specify any extension except .EXT, files found correctly - only
> files
> > that match extension exactly are displayed. But when I specify .EXT then
> > displayed all files that match this extension and all files with
> extensions
> > .EXT* i.e. longer extensions.
> >
> > Why this happens? Why only 3-char long extension wildcard produces such
> > results?
>
> The reason this happens is because the directory stores both "long" and
> "short" filenames, and you're getting matches on both forms of the name.
If
> a file has an extension of ".EXTNS", then its short name will have an
> extension of ".EXT", so the search for "*.EXT" is generating a match on
> that.
>
> You'll see exactly the same if you start a command prompt, and type the
> command "dir *.ext".
How can I avoid this behaviour?
In my case user can specify sequence of extensions like that: ".EXTN, .EXT".
This causes to some files being listed twice - not good. AFAIK, under NT one
can disable short file names generation through Registry, but it's
definitely not a solution.
I could parse extensions sequence before search to throw away extensions
longer than 3 chars, which have 3-char long brothers. But if user runs NT
and has short file names disabled some files will be missed. OK, I could
check out whether current OS is NT and whether short file names is disabled
or not.
Is it only solution to list files correctly?
Thanks in advance
Alex
Guillaume Landru
has exacly the extension you require (strstr function)
Cheers,
Guillaume.
Alex Blekhman wrote in message ...
>Consider following little program:
>
>#include <windows.h>
>#include <stdio.h>
>#include <tchar.h>
>
>int _tmain(void)
>{
>
> WIN32_FIND_DATA FindFileData;
> HANDLE hFind;
>
> LPCTSTR szExt[] = { __TEXT("*.extn"), __TEXT("*.ext"),
> __TEXT("*.ex"), __TEXT("*.e"), NULL };
>
> hFind = FindFirstFile(szExt[1], &FindFileData);
>
> if(INVALID_HANDLE_VALUE == hFind) {
> _tprintf(__TEXT("No files found.\n"));
> }
> else
>
> BOOL run = TRUE;
> while(TRUE == run) {
> _tprintf (__TEXT("%s\n"), FindFileData.cFileName);
> run = FindNextFile(hFind, &FindFileData);
> }
> FindClose(hFind);
> }
>
> return 0;
>}
>
>Working directory contains files with extensions: .EXTNS .EXTN .EXT .EX .E
>
>When I specify any extension except .EXT, files found correctly - only
files
>that match extension exactly are displayed. But when I specify .EXT then
>displayed all files that match this extension and all files with extensions
>.EXT* i.e. longer extensions.
>
>Why this happens? Why only 3-char long extension wildcard produces such
>results?
>
>Thanks in advance
>Alex
>
>
Chris Marriott
> How can I avoid this behaviour?
> In my case user can specify sequence of extensions like that: ".EXTN,
.EXT".
> This causes to some files being listed twice - not good. AFAIK, under NT
one
> can disable short file names generation through Registry, but it's
> definitely not a solution.
> I could parse extensions sequence before search to throw away extensions
> longer than 3 chars, which have 3-char long brothers. But if user runs NT
> and has short file names disabled some files will be missed. OK, I could
> check out whether current OS is NT and whether short file names is
disabled
> or not.
All I can suggest is that you look at the "long form" of each filename you
get back, compare it with your list of extensions, and throw it away if it
doesn't match.
Alex Blekhman
Many thanks.
"Guillaume Landru" <to...@titi.net> wrote in message
news:8i4udo$mdv$1...@reader1.fr.uu.net...