What the... nested fpout doesnt work?

Why oh whyyyyy (pulling my hair out) does my application hang at the final line shown here?

Code:

int Get_idlist(long key, char listdir[256])
{
   FILE *fpin, *fpout;
   char id_out[256];

   sprintf(temp,"%s\\",server_vehicledb);

   if( strlen(listdir) > 2 )
   {
       sprintf(id_out,"%s%d.%s", idlist_dir_online, key, list_ext);

       fpout = fopen("C:\\test.temp","wb");
       fprintf(fpout, "test");
       fclose(fpout);

       if( (fpin = fopen(listdir, "rb")) != NULL)
       {
           fpout = fopen(id_out, "wb");
           fprintf(fpout,"testttttt\n");

...

The file C:\test.temp is created without problems... does this have something to do with nesting the fpout inside the if( (fpin.. ? I've used this method many times before, without any problems...

Been pulling my hair out since yesterday afternoon until now... does anyone here have an idea? Thanks!!

René

To outrule "id_out" being the problem I tried:

Code:

           fpout = fopen("C:\\test1.temp", "wb");
           fprintf(fpout,"testttttt\n");

Same result: BOOM.

1. you never check if the return value of fopen is not NULL.

2. I doubt that you can use fprintf() in conjunction with a binary file, I thought only fwrite() and fread() was allowed for binary files.

Originally Posted by KONI

1. you never check if the return value of fopen is not NULL.

2. I doubt that you can use fprintf() in conjunction with a binary file, I thought only fwrite() and fread() was allowed for binary files.

Thanks for your reply KONI

1. I don't indeed, but my guess is, the return is indeed NULL... so question is, why is it NULL?

EDIT: Tested and confirmed... fpout is NULL after trying to open.


2. If that's true than I'm very lucky in the rest of my code... I use this very often without any problems. If this is not correct then please let me know so I can change it everywhere in my code
I've also tried opening with fopen(id_out,"w") by the way, and that didn't work either...


EDIT: Also, like I said in my first post, the C:\test.temp file is created and contains the string "test". That's done by using "wb" too, so I really don't think point 2 is a problem.



So I don't think the problem lies in one of your two points

You're assigning the char to it, not the file pointer....

Code:

int Get_idlist(long key, char listdir[256])
{
   FILE *fpin, *fpout;
   char id_out[256];

   sprintf(temp,"%s\\",server_vehicledb);

   if( strlen(listdir) > 2 )
   {
       sprintf(id_out,"%s%d.%s", idlist_dir_online, key, list_ext);

       fpout = fopen("C:\\test.temp","wb");
       fprintf(fpout, "test");
       fclose(fpout);

       if( (fpin = fopen(listdir, "rb")) != NULL)
       {
           fpout = fopen(id_out, "wb");
           fprintf(fpout,"testttttt\n");

...

See the colored areas in the code to see what your problem is.

I hope that is the solution ulillillia, but could you please elaborate? I don't understand what you mean, sorry.
I'm probably too deep into this to think clearly...

Okay, here's more details:

Code:

void SomeFunction()
{
	FILE *FileHandle; // this is a file handle.
	
	char SomeString[1024]; // this is a string
	long SomeData[5]; // this is just some regular data
	
	FileHandle = fopen("GiveYourPathHere.dat", "rb"); // assigns the file handle to the file as specified and read in binary mode
	fread(&SomeData, 4, 5, FileHandle); // read some data (use a byte at a time when compatibility with other computers is important)
	fclose(FileHandle); // closes the file making the handle null
	
	// other stuff
}

If you want the path specified using a string, which 256 seems a likely case, you'd use sprintf to stitch together any file name variations or, as in the example above, just a raw string as is. Better yet, perhaps you need to read this tutorial as well.

Thanks for your help!

But seriously, I don't have a clue of what I'm doing wrong. As far as I can see from your example I'm doing exactly what you're telling me to

Also, how do you explain the fact that the file C:\test.temp is created without a problem? And like I say in my post here:
What the... nested fpout doesnt work?

Why doesn't that work either? The problem is not to do with the path name as far as I can see?

Thanks again,

René

First, assign the file handle using fopen. If it fails, the return value is 0. If it succeeds, it's non zero and the value is otherwise quite random. A basic printf works for checking this:

Code:

...
FileHandle = fopen("Some file name.dat", "rb");
printf("The file handle is %d.\n", FileHandle);
...

Using printf and other text-displaying things in well-placed locations to check the flow of the program is a useful debugging tactic.

Hey I didn't know that one, thanks

Using "fpout = fopen(id_out, "wb");" I get:

The file handle is 0.

So it fails (what a surprise )... now why does it fail? What reasons are there for fopen() in write mode to fail?
As far as I know, "wb" creates the file if it doesn't exist... and it does exactly do that a couple of lines upwards... Grrr... lost.

perror(), errno, and all that.

perror ftw! THANKS MacGyver, always been a fan of your tv series

OK, this sounds quite logical to me... "Too many open files".

But what I don't understand is, as you can see from the code snippet in my first post I only have one other file open... I do open some files before I call the function get_idlist, but they are all "fclosed" before then!
I get this quite often... files that Windows say are "in use" when I'm 100% sure I've used fclose() on that file! In that case the file only gets released when I close the application...
So is there something else I need to do to close the file fully?


EDIT: found fcloseall(); but when I add it to the code I get [Linker error] undefined reference to `fcloseall' ... pffff thank god its almost weekend...

fclose() should close the file. Test it by creating a program that opens a file and waits for a keypress. After the keypress it closes the file, and waits for another keypress. During each stage when the program is running, try altering the file in question, when it's opened, closed, and then lastly when the program is shut down.

When the file is opened, depending on the settings, the file might be locked. When it's closed, any locks should be relinquished. When the program closes, any mess should be cleaned up, but it's not good to rely on that.

Make sure you're not opening the same file repeatedly in a loop or something.

Originally Posted by KONI

2. I doubt that you can use fprintf() in conjunction with a binary file, I thought only fwrite() and fread() was allowed for binary files.

It's perfectly fine to do it.

Hmmm... so I've been looking everywhere on the internet to find a solution for the "Too many open files" problem, but there doesn't really seem to be a solution for this.

I've tried changing the FOPEN_MAX value in stdio.h but this doesn't have any effect. I've checked all my fopen() calls for a corresponding fclose() and all fopens are closed afterwards...

So I seriously don't have a clue where this error message is coming from... Is there anyone here who's had a similar problem? Maybe I should start a new thread with a better title? Getting kinda desperate here... :/


Thanks for any help, René