fopen in Linux (Lubuntu) returns NULL when the file exists

Question

I'm running this on Lubuntu in a virtual machine using Oracle's VirtualBox. I don't think that would affect anything, but I just thought it was worth mentioning.

It appears the error is appearing from a strange symbol appended to the end of the string returned by the following function:

inline std::string f_settings_get(std::string val){
    int index=0;
    while(strcmp(val.c_str(),f_settings[0][index].c_str())!=0){
        index++;
    };
    // For debugging purposes - printf("\n%s\t%s",f_settings[0][index].c_str(),f_settings[1][index].c_str());
    return f_settings[1][index];
}

I can't see an issue with this function and thus believe it might be caused by the data stored in the variable.

I have been trying to open a file in my program using fopen and have come across the error stated in the title. The code works perfectly in Windows (and I have accounted for the / and \ for each operating system); however, when running on Linux, although it compiles perfectly, I get the error that the file does not exist. I checked online and found several issues others have had such as:

1. The filename is not REALLY the right filename

2. Permission to access file was not there

3. Accessing the file was done by just calling "file.txt" instead of the whole directory

I checked the first out by using the Python script supplied, and recreating the file with a new name. That didn't work (and the Python script showed that the filename was good).

I set all permissions to being 777 using chmod -R 777 clesis and that did not work (though I didn't expect it to be a permissions issue as it said the file did not exist).

I have the full path already called and double checked the path. It is correct.

Finally, I ran the following in the code to double check that: (a) The file existed and (b) I was trying to open the correct file.

    tmp_s="";
    tmp_s = homeDir+binP+f_settings_get("xxxxx"); // Note, you can easily get whatever variable you want using either f_settings_get or num_settings_get
    tmp_file = fopen(tmp_s.c_str(), "r+");
    printf("\n Running the following command: /home/xxxxx/programming/xxxxx/bin\n");
    std::system("ls -l /home/xxxxx/programming/xxxxx/bin");
    getWait();
    printf("\n Tried to open: %s", tmp_s.c_str());
    if (tmp_file == NULL){
        printf("\n");
        perror("Error loading dimensions.sim");
        printf("Press enter to exit...");
        getWait();
        exit(1);
    }

And here's how the output looks (sorry for censoring things. I assure you the user name and folder are spelled the same):

The output shows the following:

Filenames Loaded...

Loading Settings from sim file...
++++++++++++++++++++++++++++++++++++++++++++++++++ Settings Loaded...

Loading System Dimensions from sys file...
--------------------------------------------------
 Running the following command: /home/xxxxx/programming/xxxxx/bin
total 636
-rwxrwxrwx 1 xxxxx xxxxx    958 Jul 25 20:59 dimensions.sim

Tried to open: /home/xxxxx/programming/xxxxx/bin/dimensions.sim

Error loading dimensions.sim: No such file or directory
Press enter to exit...

If the file path is specified directly as "bin/dimensions.sim" or "/home/xxxxx/programming/xxxxx/bin/dimensions.sim" then it works properly. This leads me to a confused conclusion. That somewhere in the conversion of tmp_s from a std::string to a c_str there is an issue that is leading to a wrong directory path. However, this doesn't occur with any of the other files I'm using, and I have never had this issue on a Windows machine. Thus I am confused as to what may be causing it.

One last observation - the conversion was printed out anyway using the printf("tmps = %s",tmp_s.c_str());. And that can be clearly seen to not be 'weird'.

Answer 1

Your problem is most likely coming from stray carriage returns (hex 0D, usually written as \r in C), which is common when using unix-y libraries to read windows-y files. Windows files have their lines terminated with CR-LF, hex 0D0A, while unix just uses a single LF, hex 0A. Windows C stdio will map a CRLF onto a single LF (\n) for files not opened in binary mode. In Unix, it doesn't matter whether files are opened in binary or ASCII modes, since no remapping happens.

The consequence is that the same program compiled on Windows programs can read Windows files, and compiled on Unix can read Unix files; in both cases, the line-terminator will look like a single \n. Windows programs can usually read Unix files, too. But the Unix program reading a Windows file will see a stray CR, \r, hex 0D at the end of every line.

This particularly plagues configuration utilities. Suppose you have a config file of the form:

some_setting=27
some_file=dimensions.sim

etc.

Now, the configuration reader reads each line, splits it at the =, and uses the first part as a key and the second part as a value. It might even convert some of the values to numbers.

Now, if the file was created on Windows (regardless of whether it is currently sitting on Windows or sitting on your laptop), the Unix configuration reader is going to see the value of some_setting as 27\r and the value of some_file as dimensions.sim\r. The first one won't cause any problems unless the config system is paranoid, because atoi and strtod convert up to the first non-digit character, and don't complain as long as there is at least one digit. But the string will not work as a filename, because the filename is unlikely to have a \r at the end.

What makes this problem particularly insidious is that when you try to print the offending string out, the \r actually acts as a carriage return; that is, it returns the cursor to the beginning of the line. If the next output character is \n, then the \r is totally invisible. If the next output is some message, it will get overprinted over the line, which is very confusing.