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

ScreenConnect 6.0 Free Trial

At ScreenConnect, partner feedback doesn't fall on deaf ears. We collected partner suggestions off of their virtual wish list and transformed them into one game-changing release: ScreenConnect 6.0. Explore all of the extras and enhancements for yourself!

Question has a verified solution.

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

Suggested Solutions

Preface I don't like visual development tools that are supposed to write a program for me. Even if it is Xcode and I can use Interface Builder. Yes, it is a perfect tool and has helped me a lot, mainly, in the beginning, when my programs were small…
Windows programmers of the C/C++ variety, how many of you realise that since Window 9x Microsoft has been lying to you about what constitutes Unicode ( They will have you believe that Unicode requires you to use…
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use while-loops in the C programming language.
The goal of this video is to provide viewers with basic examples to understand how to create, access, and change arrays in the C programming language.

772 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