Board index » cppbuilder » _dos_findfirst and 2003 server os

_dos_findfirst and 2003 server os


2006-04-07 01:07:38 AM
cppbuilder20
Hi.
I'm using plain old Borland 5.02 with the owl it came with.
I seem to find that under Windows 2003 Server
(who would of thought that 6 years after being discontinues it would
have to provide apps to run under newer os's?)
that the "." and ".." are found, but not the other
subdirectory names.
It appears to work under Windows XP SP2.
void findTheSubDirectoryNames(szDirName)
{
strcat(szDirName,"\\*.");
nStat = _dos_findfirst( szDirName, _A_SUBDIR, &ffblk );
while(!nStat)
{
//
// Skip the directories current and one up
//
if (!strcmp(ffblk.name, "." ) || !strcmp(ffblk.name,
"..") )
{
OutputDebugString("TGetManualDlg::AddManualsToListbox() found . or ..
");
nStat = _dos_findnext( &ffblk );
continue;
}
//process the directory names here...
}
Is this just a runtime 'that is the way it is' problem, or a known
issue, or is there a better recommended work around?
Thanks,
Jeff
Jeff Kish
 
 

Re:_dos_findfirst and 2003 server os

Hi Jeff:
I suggest you to replace the functions with FindFirstFile, FindNextFile and
FindClose:
Sample code:
HANDLE h;
WIN32_FIND_DATA wf_data;
h = FindFirstFile(audioDirAux, &wf_data);
int ret = ( h != INVALID_HANDLE_VALUE);
while ( ret ) {
if (wf_data.cFileName[0]!='.' && (wf_data.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY)) {
directorios.Add(dirAprobado);
...
}
ret = FindNextFile( h, &wf_data);
}
if ( h != INVALID_HANDLE_VALUE)
FindClose(h);
findfirst and findnext leaves an 'open handle'. FindClose was created to
solve that.
Saludos
Sebastian
"Jeff Kish" < XXXX@XXXXX.COM >escribi?en el mensaje
Quote
Hi.

I'm using plain old Borland 5.02 with the owl it came with.
I seem to find that under Windows 2003 Server
(who would of thought that 6 years after being discontinues it would
have to provide apps to run under newer os's?)
that the "." and ".." are found, but not the other
subdirectory names.
It appears to work under Windows XP SP2.

...
Is this just a runtime 'that is the way it is' problem, or a known
issue, or is there a better recommended work around?

Thanks,
Jeff

Jeff Kish
 

Re:_dos_findfirst and 2003 server os

On Thu, 6 Apr 2006 14:22:53 -0300, "Sebastian Ledesma [Solidyne Labs]"
<labo[no_sp@m]solidyne1.com>wrote:
Quote
Hi Jeff:

I suggest you to replace the functions with FindFirstFile, FindNextFile and
FindClose:

Sample code:
HANDLE h;
WIN32_FIND_DATA wf_data;

h = FindFirstFile(audioDirAux, &wf_data);
int ret = ( h != INVALID_HANDLE_VALUE);
while ( ret ) {
if (wf_data.cFileName[0]!='.' && (wf_data.dwFileAttributes &
FILE_ATTRIBUTE_DIRECTORY)) {
directorios.Add(dirAprobado);
...
}
ret = FindNextFile( h, &wf_data);
}
if ( h != INVALID_HANDLE_VALUE)
FindClose(h);

findfirst and findnext leaves an 'open handle'. FindClose was created to
solve that.

Saludos
Sebastian



"Jeff Kish" < XXXX@XXXXX.COM >escribi?en el mensaje
news: XXXX@XXXXX.COM ...
>Hi.
>
<snip>
Thanks
I see that the code I was using (ancient holdover) is actually
supported under win16 and os2, not win32, so I have been probably
begging for trouble ever since we implemented 32 bit support all those
years ago.
Jeff Kish
 

{smallsort}

Re:_dos_findfirst and 2003 server os

Jeff:
You can mantain compatibility support (for political reason's) by using
#defines
Something like: //check for OWL sources to get a more specific idea
#if defined WIN16
...
#else
...
#endif
Also: Memproof it's a free on-the-fly memory leaking solution. It's not
perfect but it's free.
I use in combination with Codeguard (i have some problems using Codeguard in
XP).
www.automatedqa.com/downloads/memproof/
Saludos
Sebastian
"Jeff Kish" < XXXX@XXXXX.COM >escribi?en el mensaje
Quote
On Thu, 6 Apr 2006 14:22:53 -0300, "Sebastian Ledesma [Solidyne Labs]"
<labo[no_sp@m]solidyne1.com>wrote:

>Hi Jeff:
>
>I suggest you to replace the functions with FindFirstFile, FindNextFile
>and
>FindClose:
>
>Sample code:
>HANDLE h;
>WIN32_FIND_DATA wf_data;
>
>h = FindFirstFile(audioDirAux, &wf_data);
>int ret = ( h != INVALID_HANDLE_VALUE);
>while ( ret ) {
>if (wf_data.cFileName[0]!='.' && (wf_data.dwFileAttributes &
>FILE_ATTRIBUTE_DIRECTORY)) {
>directorios.Add(dirAprobado);
>...
>}
>ret = FindNextFile( h, &wf_data);
>}
>if ( h != INVALID_HANDLE_VALUE)
>FindClose(h);
>
>findfirst and findnext leaves an 'open handle'. FindClose was created to
>solve that.
>
>Saludos
>Sebastian
>
>
>
>"Jeff Kish" < XXXX@XXXXX.COM >escribi?en el mensaje
>news: XXXX@XXXXX.COM ...
>>Hi.
>>
<snip>
Thanks
I see that the code I was using (ancient holdover) is actually
supported under win16 and os2, not win32, so I have been probably
begging for trouble ever since we implemented 32 bit support all those
years ago.
Jeff Kish
 

Re:_dos_findfirst and 2003 server os

<snip>
Quote
Also: Memproof it's a free on-the-fly memory leaking solution. It's not
perfect but it's free.
I use in combination with Codeguard (i have some problems using Codeguard in
XP).
www.automatedqa.com/downloads/memproof/

Saludos
Sebastian
<snip>
Thanks again.
Say, do you do anything special to use it? I suppose you make sure
code guard is not turned on.. do you use codeguard at all on xp?
thanks
Jeff
Jeff Kish
 

Re:_dos_findfirst and 2003 server os

Jeff Kish wrote:
Quote
Is this just a runtime 'that is the way it is' problem, or a known
issue, or is there a better recommended work around?
Looks like questionable code to me.
Quote
void findTheSubDirectoryNames(szDirName)
{
strcat(szDirName,"\\*.");
You are assuming that directories don't have extensions.
For older DOS apps, "*.*" or newer 32bit Win apps, a simple "*"
Quote
nStat = _dos_findfirst( szDirName, _A_SUBDIR, &ffblk );
while(!nStat)
{
//
// Skip the directories current and one up
//
if (!strcmp(ffblk.name, "." ) || !strcmp(ffblk.name,
"..") )
{
OutputDebugString("TGetManualDlg::AddManualsToListbox() found . or ..
");
nStat = _dos_findnext( &ffblk );
continue;
}
//process the directory names here...
missing closing } and also the _dos_find_next if not . or ..
}
You might find the following structure easier to use:
void findTheSubDirectoryNames(szDirName)
{
strcat(szDirName,"\\*");
if( 0 == _dos_findfirst( szDirName, _A_SUBDIR, &ffblk ) )
{
do{
if( 0==strcmp(ffblk.name, "." ) ||
0==strcmp(ffblk.name,"..") )
{
// Skip the directories current and one up
OutputDebugString(
"TGetManualDlg::AddManualsToListbox() found . or ..");
}else{
//process the directory names here...
};
}while( 0 == _dos_findnext( &ffblk ) );
_find_close( &ffblk );
};
}
 

Re:_dos_findfirst and 2003 server os

On Thu, 06 Apr 2006 14:52:41 -0700, Bob Gonder
< XXXX@XXXXX.COM >wrote:
Quote
Jeff Kish wrote:

>Is this just a runtime 'that is the way it is' problem, or a known
>issue, or is there a better recommended work around?

Looks like questionable code to me.

>void findTheSubDirectoryNames(szDirName)
>{
>strcat(szDirName,"\\*.");

You are assuming that directories don't have extensions.
For older DOS apps, "*.*" or newer 32bit Win apps, a simple "*"

Yes. This is a custom situation. But I understand completely.
Quote
>nStat = _dos_findfirst( szDirName, _A_SUBDIR, &ffblk );
>while(!nStat)
>{
>//
>// Skip the directories current and one up
>//
>if (!strcmp(ffblk.name, "." ) || !strcmp(ffblk.name,
>"..") )
>{
>OutputDebugString("TGetManualDlg::AddManualsToListbox() found . or ..
>");
>nStat = _dos_findnext( &ffblk );
>continue;
>}
>//process the directory names here...

missing closing } and also the _dos_find_next if not . or ..
>}

You might find the following structure easier to use:

void findTheSubDirectoryNames(szDirName)
{
strcat(szDirName,"\\*");
if( 0 == _dos_findfirst( szDirName, _A_SUBDIR, &ffblk ) )
{
do{
if( 0==strcmp(ffblk.name, "." ) ||
0==strcmp(ffblk.name,"..") )
{
// Skip the directories current and one up
OutputDebugString(
"TGetManualDlg::AddManualsToListbox() found . or ..");
}else{
//process the directory names here...
};
}while( 0 == _dos_findnext( &ffblk ) );
_find_close( &ffblk );
};
}

Thanks.
 

Re:_dos_findfirst and 2003 server os

Codeguard works fine inside the IDE tracking memory overruns.
When working outside it fails to indicate the equivalent source file & line.
As I know, this can be solved by replacing the codeguard .DLL's with the
ones from BCB (didn't tested).
Also another way to fix it's by indicating the in Options->Project
options->Linker: 32-bit images, differents values,
but also I didn't check this option.
Saludos
Sebastian
"Jeff Kish" < XXXX@XXXXX.COM >escribi?en el mensaje
Quote
<snip>
>Also: Memproof it's a free on-the-fly memory leaking solution. It's not
>perfect but it's free.
>I use in combination with Codeguard (i have some problems using Codeguard
>in
>XP).
>www.automatedqa.com/downloads/memproof/
>
>Saludos
>Sebastian
<snip>
Thanks again.
Say, do you do anything special to use it? I suppose you make sure
code guard is not turned on.. do you use codeguard at all on xp?
thanks
Jeff
Jeff Kish
 

Re:_dos_findfirst and 2003 server os

If you are writing in C++ there is something else you can do.
Write a class for finding files. Let the class do the first find in the
constructor and the close of the find handle in the destructor. Provide a
function in the class to return the next file found. Each that function is
called it returns the previously found file name and info and also looks for
the next file.
Declare an instance of that class in a function. When the function returns,
the class will go out of scope and its destructor will be called. The file
search handle is automatically closed and any class memory associated with
the searching automatically freed.
You can create 3 versions of the class, one each for DOS, 16 bit Windows and
32 bit Windows. Use the appropriate file search functions for the platform
in each of the 3 versions. The interface to the class is identical for each
so your code need not change. Once debugged, no CodeGuard apply because it
releases everything automatically.
. Ed
Quote
Jeff Kish wrote in message
news: XXXX@XXXXX.COM ...
 

Re:_dos_findfirst and 2003 server os

It seems that under Windows Server 2003 wild card symbol '*' is processed
differently then it should be proceesed for other operational system. As you
know under old operational system (DOS, some version of Windows) any symbol
after '*' is ignored. A point after '*' is considered as the start of
extension. But when you using new search functions as FineFirstFile() and
FindNextFile() with using WIN32_FIND_DATA you can place any symbol after
'*'.
For example, the specification "*1" denotes all files ended with '1'. It
seems that in your case you get all directories which ended with '.'. From
my point of view this is incompatiblity Windows Server 2003 with other
operational system.
You can test this with my simple demo. It has a mode with which you can
specify any file specification for searching. Try it! It is interesting what
results you will get.
The demo you can see here
hyperupload.com/download/01b0e62972/FS_DEMO1.EXE.html
The corresponding source code of the demo is here
hyperupload.com/download/0283d25183/FS_DEMO1.PRG.html
Vladimir Grigoriev
"Jeff Kish" < XXXX@XXXXX.COM >wrote in message
Quote
On Thu, 06 Apr 2006 14:52:41 -0700, Bob Gonder
< XXXX@XXXXX.COM >wrote:

>Jeff Kish wrote:
>
>>Is this just a runtime 'that is the way it is' problem, or a known
>>issue, or is there a better recommended work around?
>
>Looks like questionable code to me.
>
>>void findTheSubDirectoryNames(szDirName)
>>{
>>strcat(szDirName,"\\*.");
>
>You are assuming that directories don't have extensions.
>For older DOS apps, "*.*" or newer 32bit Win apps, a simple "*"
>
Yes. This is a custom situation. But I understand completely.

>>nStat = _dos_findfirst( szDirName, _A_SUBDIR, &ffblk );
>>while(!nStat)
>>{
>>//
>>// Skip the directories current and one up
>>//
>>if (!strcmp(ffblk.name, "." ) || !strcmp(ffblk.name,
>>"..") )
>>{
>>OutputDebugString("TGetManualDlg::AddManualsToListbox() found . or ..
>>");
>>nStat = _dos_findnext( &ffblk );
>>continue;
>>}
>>//process the directory names here...
>
>missing closing } and also the _dos_find_next if not . or ..
>>}
>
>You might find the following structure easier to use:
>
>void findTheSubDirectoryNames(szDirName)
>{
>strcat(szDirName,"\\*");
>if( 0 == _dos_findfirst( szDirName, _A_SUBDIR, &ffblk ) )
>{
>do{
>if( 0==strcmp(ffblk.name, "." ) ||
>0==strcmp(ffblk.name,"..") )
>{
>// Skip the directories current and one up
>OutputDebugString(
>"TGetManualDlg::AddManualsToListbox() found . or ..");
>}else{
>//process the directory names here...
>};
>}while( 0 == _dos_findnext( &ffblk ) );
>_find_close( &ffblk );
>};
>}
>
Thanks.
 

Re:_dos_findfirst and 2003 server os

Sorry I have said many incorrect.
In your case when you specify template "\\*." you in fact try to search all
files and directories that have not extensions. As it seems there are not
any other direcories except of "." and ".." and there are files without
extensions you get what you have i.e. you get two entry one for "." and
another for "..". If you want get all files indeed you should specify a
search template as "\\*.*". If you want get only directories you should test
attributes of a searched file against of _A_SUBDIR.
Vladimir Grigoriev
"Vladimir Grigoriev" < XXXX@XXXXX.COM >wrote in message
Quote
It seems that under Windows Server 2003 wild card symbol '*' is processed
differently then it should be proceesed for other operational system. As
you
know under old operational system (DOS, some version of Windows) any
symbol
after '*' is ignored. A point after '*' is considered as the start of
extension. But when you using new search functions as FineFirstFile() and
FindNextFile() with using WIN32_FIND_DATA you can place any symbol after
'*'.
For example, the specification "*1" denotes all files ended with '1'. It
seems that in your case you get all directories which ended with '.'.
From
my point of view this is incompatiblity Windows Server 2003 with other
operational system.
You can test this with my simple demo. It has a mode with which you can
specify any file specification for searching. Try it! It is interesting
what
results you will get.

The demo you can see here
hyperupload.com/download/01b0e62972/FS_DEMO1.EXE.html
The corresponding source code of the demo is here
hyperupload.com/download/0283d25183/FS_DEMO1.PRG.html

Vladimir Grigoriev

 

Re:_dos_findfirst and 2003 server os

On Tue, 11 Apr 2006 13:05:36 +0400, "Vladimir Grigoriev"
< XXXX@XXXXX.COM >wrote:
Quote
Sorry I have said many incorrect.
In your case when you specify template "\\*." you in fact try to search all
files and directories that have not extensions. As it seems there are not
any other direcories except of "." and ".." and there are files without
extensions you get what you have i.e. you get two entry one for "." and
another for "..". If you want get all files indeed you should specify a
search template as "\\*.*". If you want get only directories you should test
<snip>
Thanks
Jeff
Jeff Kish