Cannot open particular file name to append - c

I have some code which iteratively appends data to a file and looks similar to:
for(int i=0; i<number; i++){
FILE *log_file;
char name[50];
sprintf(name,"something_%d.log",i);
log_file=fopen(name,"a");
if(log_file == NULL){
printf("ERROR cannot open file %s",name);
abort();
}
/* Write stuff to file */
fclose(log_file);
}
Seems simple enough right? If the file exists and I have permission to write to it, it proceeds as normal; if the file does not exist and I have permission to write files in the directory, it creates the file as normal. WRONG! Somehow, when I come across a particular file name (MINI_3f_1_0.log) the program cannot create/open the file and yields log_file = NULL. Obviously this is not my entire code, and the worst thing is that I cannot reproduce this problem with a simple program as shown.
I have already spent a few hours trying to track down what is going on, and so far I am 100% sure of the following:
The file is declared, opened, and closed within the same scope
A file of the same name is not open in any other function/the entire program
I have permission to read/write in the directory
Trying to open the file out of the iterative order produces the same error when it is done in the same routine
Any guidance you guys/gals can give me would be greatly appreciated. If you have come across anything like this in your experience, how did you fix it?

As suggested by Mat in the comments,running the code in a different directory did not produce the error. There is something likely wrong with the file system and needs to be looked into by the sys-admin.

Related

Fopen - No such file or directory in C

This code does not open file properly, it returns no such file or directory, although the path and privilege are there and no other program is using the file. How can I fix the error? I tried swapping the path and moving the file, the error is there still.
char string[105];
FILE* file = fopen("C:\\Users\\Public\\Documents\\a.txt", "r");
while (fgets(string, 100, file)) {
printf("%s", string);
}
It can be surprisingly tricky to open a simple file! Lots of things can go wrong. I recommend writing slightly more verbose code, like this:
#include <string.h>
#include <errno.h>
char* filename = "C:\\Users\\Public\\Documents\\a.txt";
char string[105];
FILE* file = fopen(filename, "r");
if (file == NULL) {
fprintf(stderr, "can't open %s: %s\n", filename, strerror(errno));
exit(1);
}
while (fgets(string, 100, file)) {
printf("%s", string);
}
The point is that the error message prints out both the name of the file it tried but failed to open, and the actual reason it couldn't open it. (Also, by storing the filename in a variable, you make it absolutely certain that the filename it prints in the error message is the filename it tried but failed to open.) It sounds like you already know that the error was "no such file or directory", but I'm not sure how you know this.
Even though I've been programming in C for a long time, sometimes I still have this problem. One thing I'll sometimes do is use my mouse to copy the exact filename string printed in the error message, the file the program said it couldn't open, the file I'm sure is really there, and paste it into a terminal window (or CMD or Powershell if you're on Windows), along with a directory-listing command, to see if the operating system can actually see the file. That is, for your example, the command I'd run is
dir C:\Users\Public\Documents\a.txt
but the point is that I would not actually type the pathname "C:\Users\Public\Documents\a.txt", instead I would copy and paste it out of the error message that the program printed. Sometimes there are surprising little impossible-to-spot differences between the filename you thought it was trying to open, versus the filename it was actually trying to open, and this exercise is a good way to let the computer help you find those differences.
Remember, too, that you'll get the error "No such file or directory" if there's no file by that name in the directory, or if the directory isn't there at all. For example, if you're trying to open the path
C:\Users\Public\Documents\a.txt
and the file a.txt keeps not being there, and you keep checking your home directory
C:\Users\Donkey\Documents
and you keep seeing that the file is there, it can be surprisingly easy to overlook what the real problem is. :-)
Addendum: You might be having an issue with the different Unix/Linux versus Windows file path separators, that is, / versus \. Usually, on a Windows machine, it's safest to use \, as you've done. (One very frequent mistake is to forget to double the backslashes, but it looks like you got that right.) Depending on your programming environment, if there's some level of Unix emulation going on, you can sometimes use Unix-style /, and it will automatically translate to \ for you. I've never heard of a situation where using \ made it not work (which is a possibility being explored in the comments), but you might experiment with that, perhaps trying
char* filename = "/c/Users/Public/Documents/a.txt";
or (less likely)
char* filename = "C:/Users/Public/Documents/a.txt";

Open file in a different directory

I have to do a simple task. I have to open a file which is in a directory. I have the .c file in src, when I compile I move the programs (a.out) in the a bin directory. I want to read a file in the directory asset. All these folders are in a main folder.
If I do this
FILE* fp = fopen("../asset/team_list", "r");
it won't open the file. Why can't I open the file in that directory?
guess you forgot to put the extension of your file
FILE* fp = fopen("../asset/team_list.doc", "r");
Find what error you get using perror/explicit mention of error message and expect a possible reply from stackoverflow.
Make sure you are pointing out to the correct directory where the file is present from the PWD from where your program is being executed.
Relative paths are relative to the current working directory of the process, which might not be the same location as the binary file. So, if you are in /home/user/ and you run ./project/bins/my.exe then your current working directory is /home/user/, relative paths need to be relative to that location.
You can try a few things to help with this issue. First, after the failed open you could examine errno to see why the open failed, is it permissions, invalid path?
Alternatively you might have access to the strace program, this traces system calls, like open from your application, and will allow you to see the failed system call. Try strace ./project/bins/my.exe, you'll see a lot of output, dig through this looking for the failed open call, and try to figure out why this is failing, again the errno will be included in the trace to help understand the failure.
Lastly, you could just add a call to getcwd to your program and print the result (as a debugging aid), this places the current working directory into a buffer, something like this:
char buffer [PATH_MAX + 1];
getcwd (buffer, PATH_MAX + 1);
printf (buffer);

working with files on "start without debugging"

I'm programming in C, and
I have the following problem:
I use fopen and try to read from a csv file, that is currently storred in the folder of the exe file of the program.
the program works fine in debug mode and release mode, but when I try to run the program in "start without debugging" on visual studio 2008 express edition, the program stops working and windows is showing a message: "*.exe has stopped working. a program caused the program to stop working correctly. windows will close the program and notify you if a solution is available".
I've tried running the program on several computers, and it's the same.
another information I can give you is that if I enter the full path of the file (C:....file.csv) - then is works just fine, without any problem.
I know I didn't write any code, but I hope someone will have an idea why this can happend.
thanks is advance.
Your program is not finding the csv file, fopen() fails and return a null pointer, you try to use it without checking and your program crashes (just my guess).
Firstly, you must make a check to see if fopen() could indeed open your file:
FILE* f = fopen("file.csv", "r");
if(f == NULL) {
/* print some meaningful error */
} else {
/* use the file */
}
Secondly, you may solve the problem by executing your program from the same folder the file is present. I am not a Windows guy, but if you create a link to the ".exe", in its properties may have some configuration called "Working Directory" or something like that, that you may set to the path on where the file can be found.
Every process has a working directory, that is usually the directory from where it was started, though it may be inherited from the parent process and it may be changed programmatically. If you do not specify the full path when loading a file, the process will search for the file in its current working directory.

fopen in C(Linux) returns "Too many open files"

static char filename[128] = "trace.txt";
g_file = fopen(filename, "w");
if(NULL == g_file)
{
printf("Cannot open file %s.error %s\n",filename,strerror(errno));
exit(1);
}
I am trying to open a empty text file named trace.txt in write mode (in my working directory.)
The program is creating an empty file trace.txt in my directory.but the check (NULL == g_file)
is returning true and it is returning error code 24 (Too many open files.).Any idea why this is.This is the first file I am opening in my program.
Surprisingly the code is creating an empty file in my working directory by the name specified.However the check for null file pointer is succeeding for some reason.? :(
You probably have a file descriptor leak.
If your code keeps opening files, never closing them, you will reach the limit sooner or later, and then fopen will fail.
You can check this by printing the file descriptor numbers you get whenever opening a file. If they keep growing, you have a leak.
It is most likely due to your system reaching its maximum allowed open file handles.
You can easily test this by running the following:
$ dd if=/dev/urandom of=test.dat bs=16 count=1
If you are out of file handles, this should provide the same or similar error.
You can trouble shoot this using some of the following commands:
To see the maximum allowed open files:
$ cat /proc/sys/fs/file-max
To see the which files are currently open (remember this includes device files, sockets, etc):
$ lsof
You can also use lsof to get a count of open files:
$ lsof | wc -l
This looks like a similar issue to what you're having, but I'm not entirely sure if it will help you solve the problem. Might be worth a look:
Problem with writing to file in C
Correct, I faced same error message and found that I was trying to close the file in a function but not where it was opened. So I then closed in the function where it was opened, later everything went fine.

C Programming fopen() while opening a file

I've been wondering about this one. Most books I've read shows that when you open a file and you found that the file is not existing, you should put an error that there's no such file then exit the system...
FILE *stream = NULL;
stream = fopen("student.txt", "rt");
if (stream==NULL) {
printf(“Cannot open input file\n”);
exit(1);
else {printf("\nReading the student list directory. Wait a moment please...");
But I thought that instead of doing that.. why not automatically create a new one when you found that the file you are opening is not existing. Even if you will not be writing on the file upon using the program (but will use it next time). I'm not sure if this is efficient or not. I'm just new here and have no programming experience whatsoever so I'm asking your opinion what are the advantages and disadvantages of creating a file upon trying to open it instead of exiting the system as usually being exampled on the books.
FILE *stream = NULL;
stream = fopen("student.txt", "rt");
if (stream == NULL) stream = fopen("student.txt", "wt");
else {
printf("\nReading the student list directory. Wait a moment please...");
Your opinion will be highly appreciated. Thank you.
Because from your example, it seems like it's an input file, if it doesn't exist, no point creating it.
For example if the program is supposed to open a file, then count how many vowels in it, then I don't see much sense of creating the file if it doesn't exist.
my $0.02 worth.
Argument mode:
``r'' Open text file for reading.
``r+'' Open for reading and writing.
``w'' Truncate file to zero length or create text file for writing.
``w+'' Open for reading and writing. The file is created if it does not
exist, otherwise it is truncated.
``a'' Open for writing. The file is created if it does not exist.
``a+'' Open for reading and writing. The file is created if it does not
exist.
Your question is a simple case. Read above description, when you call fopen(), you should decide which mode shall be used. Please consider why a file is not created for "r" and "r+", and why a file is truncated for "w" and "w+", etc. All of these are reasonable designs.
If your program expects a file to exist and it doesn't, then creating one yourself doesn't make much sense, since it's going to be empty.
If OTOH, your program is OK with a file not existing and knows how to populate one from scratch, then it's perfectly fine to do so.
Either is fine as long as it makes sense for your program. Don't worry about efficiency here -- it's negligible. Worry about correctness first.
You may not have permission to create/write to a file in the directory that the user chooses. You will have to handle that error condition.

Resources