_findfirst() OK, _findnext() fails after finding next

[fopetesl]

Debug doesn't track error.
After displaying second file program seems to go into endless loop taking 25% of processor with no other output.

/*
        24/01/2017      09:40
*/

#include <stdio.h>
#include <sys\stat.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <dos.h>
#include <conio.h>
#include <ctype.h>
#include <io.h>
#include <math.h>
#include <dir.h>
#include <errno.h>
#include <process.h>

#define uint unsigned int
#define uchar unsigned char
#define byte unsigned char
#define ulong unsigned long

FILE *outfileF,   // to write DTB files
     *outfileR,
     *infile;

uint iFdata[3000],  /* DTB extracted data                    */
     itemp[3000],
     iRdata[3000];

int main( void)
{
   struct _finddata_t ffblk;
   intptr_t handle = 0;
   char *dir_buffer, cdir[64];
   int ii = 0, in, i, iLen, iSum;
   char csFileF[14], csFileR[14]; /* corrected file names       */

   printf("\n  Churns out two files from your AL2ooo 001 data files [hit enter]");
   getch();

   dir_buffer =_getcwd( (char *)&cdir, sizeof(cdir));
   if( !dir_buffer) {
     printf("\n ! ERROR ! obtaining current disc directory!");
     printf("\n .. any key ..");
     getch();
     exit(-1);
   }
   printf("\nDirectory: %s\n", cdir);

   handle = _findfirst("*.001", &ffblk);
   if( handle == -i) { printf("\nNO FILES!\n"); exit(-1);}
   while( handle && !ii ) {  // ii set by _findnext()
     if( !ii)  {
       printf("\n%12s  ",ffblk.name);
       for( i = 0x0; ffblk.name[i] != '.'; ++i )
         csFileF[i] = csFileR[i] = ffblk.name[i];
       csFileF[i] = csFileR[i] = 0;
       strncat(csFileF, "F.dtb", 5);
       strncat(csFileR, "R.dtb", 5);
       printf(" File: %i \n", handle);
       printf("%s  ",csFileF);
       printf("%s\n",csFileR);
       infile = fopen(ffblk.name, "r");
        if( infile ) {
         i = fseek( infile, 0x80L, SEEK_SET);
         if(!i) {
           in = fread(&iLen, 2, 1, infile);
           printf("[%d]AL100 bytes %x[%d]\n", in, iLen, iLen);
         }
        else
         {  printf( "\n!!ERROR READING FILE!! %s\n", ffblk.name); fclose(infile); exit(-1); }

       }
       printf("...next..");
     ii = _findnext(handle,&ffblk);
       printf("[%d]is..%12s %i\n",ii, ffblk.name, handle);
       if( ii == -1 )
        printf("an error: %s\n", strerror(errno));
// exit(-1);
     }
   } // while( handle...

   _findclose(handle);
   return( 0);
}/* ..end.. main()  */

[Salem]

Can you paste the output of
dir /n/x c:\CSV_2_DTB\CVS2DTB

You're obviously using Windows and a 32-bit compiler, but you're using the archaic DOS API with it's inherent 8.3 filename issues (and no doubt other problems as well).

[fopetesl]

Can you paste the output of
dir /n/x c:\CSV_2_DTB\CVS2DTB

You're obviously using Windows and a 32-bit compiler, but you're using the archaic DOS API with it's inherent 8.3 filename issues (and no doubt other problems as well).

I actually have cured this problem. I was switching between Debug & Release Modes and the issue disappeared, see the screen shot which I hadn't realised looks now OK.

However, switching Mode to Release throws an error which isn't there in Debug Mode:

i = fseek( infile, 0x80L, SEEK_SET);
         if(!i) {
           in = fread(&iLen, 2, 1, infile);
           printf("[%d]AL100 bytes %x[%d]\n", in, iLen, iLen);

In Debug I get what I need from the file, in Release Mode it's spits out garbage. Lower is output of Release Mode.

DOS 8:3 mode. No choice. I have been tasked to convert some data files from 2003 into a different format. Input files are DOS format, output is Windows format.

[Salem]

The internal format of the files is irrelevant at this stage.
The files exist on a 32-bit (or 64-bit) platform with NTFS as the filesystem.
Accessing NTFS through archaic DOS API's like _findfirst is likely to cause you grief at some point.

See FAQ > Accessing a directory and all the files within it - Cprogramming.com

> in = fread(&iLen, 2, 1, infile);
You declare iLen as an integer (presumably 4 bytes), of which the high word remains garbage following your fread of only 2 bytes.
You can see from the hex that both low words are 0x026e

Oh, and one more thing, you need to open binary files with the mode "rb".
Otherwise, you're going to get surprises whenever there is an 0x0a byte in your data stream.

> I was switching between Debug & Release Modes and the issue disappeared
This is NEVER a solution.
If code is working differently between debug and release modes, it means 99.99% of the time that there is a problem in your code.
The "works" case is merely down to pure dumb luck and not programmer skill.

The remaining 0.01% would be a compiler bug, but those are pretty rare.

[fopetesl]

I bow to your greater knowledge, Salem.
Thank you for the help.
It's been 12 years since I wrote code and then only in C so as you note, I'm still pretty rusty. Not only that but three score years and ten don't help

This is a use once only program when it's finished so I won't have to worry about future bugs appearing.

Thanks for the link though I was always leery of recursion.