fopen() failing

Question

I have a C++ program that syncs files with a remote server when windows xp starts. A function that needs to open a public key file fails at fopen(). When I start the program myself (from within explorer) everything works fine. But when I add a startup key to the registry the function fails.

I traced the code through a debugger and everything's fine until the call to CreateFileA(). CreateFileA returns FILE_NOT_FOUND.

I removed the call to fopen() and replaced it with a call to CreateFileA() directly. Then I changed SECURITY_ATTRIBUTES to NULL after which the call to CreateFileA() works.

The problem is that the 3rd party library I'm using for my encryption needs a FILE* object instead of just the data read from the file. How can I solve my problem?

Here's the code I'm currently using:

if( !GetModuleFileNameA(NULL, Path, MAX_PATH) ){
    delete [] buf;
    delete [] Path;
    return strerror( errno );
}

rPath = Path;

delete [] Path;

ret = rPath.find_last_of( '\\' );

if( ret == string::npos ){
    delete [] buf;
    return strerror( errno );
}

ret++;

rPath.erase( rPath.begin() + ret, rPath.begin() + rPath.size() - ret );

rPath += "rsa_pub.txt";

if( ( f = fopen( rPath.c_str(), "rb" ) ) == NULL ){  // fails when started from registry
    delete [] buf;
    return strerror( errno );
}

EDIT:

I found a hackery solution to the problem: if I free the runtime library and then reload it the problem goes away. However this isn't a very elegant solution. Is it perhaps possible to reset the runtime withouth removing and reloading the dll?

possible duplicate of [Is there a Windows equivalent to fdopen for HANDLEs?](http://stackoverflow.com/questions/7369445/is-there-a-windows-equivalent-to-fdopen-for-handles) — Ben Voigt, Apr 20 '12 at 16:28
I'm going to try that, but even so. This is an entirely different situation. Why is fopen() not function like it should? — user513647, Apr 20 '12 at 16:31
Your reference to security attributes suggests that it runs with different permissions when launched from the registry vs. when you launch it. What are the permissions of the file you are opening? — AShelly, Apr 20 '12 at 16:36
Did you print the value of `rPath` before the `fopen` to check its contents? — mfontanini, Apr 20 '12 at 16:37
The only question in your question is "How can I solve my problem?", right after "The problem is that the 3rd party library...needs a FILE* object". So I interpreted that to mean, "How can I turn a HANDLE from CreateFileA (which works) into a FILE* usable by the library?" And that's a duplicate. — Ben Voigt, Apr 20 '12 at 16:38
@AShelly: I can't find the permissions of the .txt file, where do I find them? It's probably read and write since I'm running as an administrator on my dev system. — user513647, Apr 20 '12 at 16:42
Is this real code, or is it just a "sketch"? I don't believe it can work in any situation because of the broken `erase` call. Yet, the OP claims that it worked when executed from Explorer. How is that possible? — AnT stands with Russia, Apr 20 '12 at 16:48
It's real code. The string is left uninitialised until the I assign Path. And it does work. — user513647, Apr 20 '12 at 16:52

score 1 · Accepted Answer · answered Apr 20 '12 at 16:37

Your rPath.erase call doesn't seem to make much sense

rPath.erase( rPath.begin() + ret, rPath.begin() + rPath.size() - ret );

What is that supposed to do?

Here you are using the (iterator, iterator) version of erase here. I beleve you are trying to erase the tail portion of the string beginning from the position ret. In that case I would expect it to look as

rPath.erase( rPath.begin() + ret, rPath.end() );

If you wanted to use the (position, length) version of erase, then it would look as

rPath.erase( ret, rPath.size() - ret );

But your specific usage looks like a weird hybrid of the two. What are you trying to do by that call?

The GetModuleFileNameA probably returns different strings, depending on how you start your program, which is why your code might appear to "work" in some cases.

It's not rPath that is the problem. I've tested the contents in both situations, and they are equal. You are right about the itarators though, silly me :O — user513647, Apr 20 '12 at 16:40
Well, sorry, but if what you tested really looks the way it looks in the original post, it simply cannot work correctly (except for a random strike of luck). This problem cannot be ignored. Until you fix it, there's no much point in trying to look for any other issues. — AnT stands with Russia, Apr 20 '12 at 16:43

fopen() failing

1 Answers1