Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2864
  • Last Modified:

finding files problem. using findfirst and findnext

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?

Thanks,

here is my code:

      struct ffblk fileinfo;
      int iDone;
      char fileName[30];
      char fileFolder[30];
      
      //find all dsfbsxxx.dbf
      sprintf(fileFolder,"scale\\data\\sale%d\\*.*",saleID);
      iDone = findfirst(fileFolder, &fileinfo, 0);
      while(!iDone)
      {
            sprintf(fileName, "scale\\data\\Sale%d\\%s",saleID, fileinfo.ff_name);
            AddFileToList(fileName);
            iDone = findnext(&fileinfo);
      }
0
Koderiter
Asked:
Koderiter
  • 2
2 Solutions
 
mikem_2auCommented:
maybe this can help?
or maybe not!

copy & paste FROM  ->   http://www.oucs.ox.ac.uk/documentation/userguides/c/l922.pdf



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
directory.

/* 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:
ANSI C
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.
0
 
AxterCommented:
>> 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.

0
 
AxterCommented:
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.
0
 
KoderiterAuthor Commented:
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.

0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now