finding files problem. using findfirst and findnext

Posted on 2003-10-23
Last Modified: 2012-06-27
I'm trying to get all the files in a directory and add them to a list. My problem is, is that the findnext function is not finding any more files in the directory even though I know there are more files. My goal is to find all the ds*.dbf files, but the code will only find 1 file and then exit. Can anybody see what is going on?


here is my code:

      struct ffblk fileinfo;
      int iDone;
      char fileName[30];
      char fileFolder[30];
      //find all dsfbsxxx.dbf
      iDone = findfirst(fileFolder, &fileinfo, 0);
            sprintf(fileName, "scale\\data\\Sale%d\\%s",saleID, fileinfo.ff_name);
            iDone = findnext(&fileinfo);
Question by:Koderiter
  • 2

Accepted Solution

mikem_2au earned 125 total points
ID: 9612179
maybe this can help?
or maybe not!

copy & paste FROM  ->

findfirst() initialises the search and fills in a structure giving details of the first
matching file (if there is one). Repeated calls to findnext() will find all remaining
matching files. Both functions return -1 if no match is found.

  int findfirst(const char *pathname,
            struct ffblk *ffblk, int attrib);
  int findnext(struct ffblk *ffblk);

The prototypes for findfirst() and findnext() are in dir.h .
The structure called ffblk is defined in dir.h to be

struct ffblk /* struct used by findfirst() and findnext()
        char ff_reserved[21]; /* reserved by DOS */
        char ff_attrib; /* attribute found */
        int ff_ftime; /* file time */
        int ff_fdate; /* file date */
        long ff_fsize; /* fil e size */
        char ff_name; /* found file name */

The file attributes are set by MS-DOS (they are nothing to do with C). They are

Bit       Hex       Indicates
0      0x01       read only
1       0x02       hidden
2       0x04       system
3       0x08       volume label
4       0x10       sub-directory
5       0x20      archive bit
6      0x40      unused
7       0x80       unused

Each individual attribute is set by setting a particular bit of an 8 bit byte.
The rules for finding files with specific attributes are rather strange, again this is a
“feature” of MS-DOS and has nothing to do with the functions provided by Borland or
other compiler manufacturers:

“Any combination of the hidden, system or directory attribute bits will match
normal files as well as those with the attributes given. If a volume label
attribute is used, then only the disk label will match. The archive and readonly
bits do not apply to the search.”

To find files with combinations of attributes the separate attributes must be bitwise
ORed together.

The following program will print the names of all C source files in the current

/* findfirst and findnext example */
#include <stdio.h>
#include <dir.h>

int main(void)
struct ffblk ffblk;
int done;

printf("Directory listing of *.*\n");
done = findfirst("*.*",&ffblk,0);
while (!done)
    printf(" %s\n", ffblk.ff_name);
    done = findnext(&ffblk);
return 0;

It is usually best to use the highest level interface available to a given operation, that is:
Vendor specific C function
DOS interrupt
BIOS interrupt

The higher the level, the more protected you are from specific models of the IBM PC,
specific versions of MS-DOS and specific compilers. Choose an ANSI C function if at
all possible for the most portable solution.
LVL 30

Assisted Solution

Axter earned 125 total points
ID: 9614112
>> sprintf(fileFolder,"scale\\data\\sale%d\\*.*",saleID);

The sprintf code does not have drive letter or the main start starting point for your path.
Since the code is missing the starting point for your path, you have to make sure that "scale" is a sub directory from where the code is running.

The problem may be that your executable is launching from a different location in which "scale" is not a sub directory.

LVL 30

Expert Comment

ID: 9614118
I recommend you use a fully qualified path to test your code first, and once you have it working with a fully qualified path, you can then trouble shoot the problem as to where your executable is actually running from.

Author Comment

ID: 9639681
Thanks for your comments.. they have helped me understand better how the find function works. I fiqured out that the variables filename and filefolder were not declared to be big enough. I changed them to filename [50] and filefolder[50] and that did fixed it.  

Another Note: The reason that I did not declare a starting point for my path is that the program can be installed into an unknown directory, but the scale folder will always be in that directory.

Thanks again for your help.


Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This tutorial is posted by Aaron Wojnowski, administrator at  To view more iPhone tutorials, visit This is a very simple tutorial on finding the user's current location easily. In this tutorial, you will learn ho…
Examines three attack vectors, specifically, the different types of malware used in malicious attacks, web application attacks, and finally, network based attacks.  Concludes by examining the means of securing and protecting critical systems and inf…
The goal of this video is to provide viewers with basic examples to understand and use structures in the C programming language.
The goal of this video is to provide viewers with basic examples to understand how to use strings and some functions related to them in the C programming language.

830 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question