4

I'm trying to use CreateFile function, but it does not go as planned.

I did a simple test code :

#include <Windows.h>
#include <iostream>
#include <tchar.h>

using namespace std;

int main() {
    HANDLE hFile;
    hFile = CreateFile(_T("test.txt"), GENERIC_READ, NULL, NULL, OPEN_EXISTING, NULL, NULL);
    if (hFile == INVALID_HANDLE_VALUE) {
        cout << GetLastError() << endl;
        Sleep(2000);
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

I generate the .exe and place a file test.txt in the same folder.

When I execute the .exe I get getLastError() = 2 which means ERROR_FILE_NOT_FOUND

How is it even possible?

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
plowed
  • 49
  • 3
  • 4
    If this is in Visual Studio the default folder (unless you changed the `Working Directory` setting in debug settings) is not the same as the executable. It will be same folder as the project. – drescherjm Jul 05 '17 at 20:27
  • Hello, I launch the .exe myself by double clicking on it in the folder "Release". – plowed Jul 05 '17 at 20:29
  • 5
    Maybe your file has two .txt extensions. Windows adds confusion by hiding extensions. You may actually have `test.txt.txt` when you wanted `test.txt` – drescherjm Jul 05 '17 at 20:30
  • I dont know if i am stupid or you are a genius, but thank you this is the exact problem... – plowed Jul 05 '17 at 20:34
  • 1
    Please learn about a programs *current working directory* (`getcwd()` is useful) and how to change it (`chdir()` for example). – Jesper Juhl Jul 05 '17 at 20:34
  • My advice is to disable the "Hide Extensions for known types" in your view settings for explorer. This is one of the first things I always do when setting up a new windows box. – drescherjm Jul 05 '17 at 20:35
  • ***if i am stupid or you are a genius, but thank you this is the exact problem*** This is a reasonably common issue here. I have seen it dozens of times. – drescherjm Jul 05 '17 at 20:36
  • @JesperJuhl: The only thing you need to know about the current working directory is to not ever use it. As a per-process property it is unreliable, and generally not under your control. – IInspectable Jul 05 '17 at 21:26
  • @IInspectable it's completely reliable if your program makes sure to always change it to what it needs to be as its first order of business. – Jesper Juhl Jul 05 '17 at 21:35
  • @JesperJuhl: How do you control a per-process property in a multi-threaded environment, where you don't even control creation of all threads? – IInspectable Jul 05 '17 at 21:40
  • @JesperJuhl: Or the fact that some system APIs, like dialogs, also can change the CWD. Best to NEVER rely on relative paths, ALWAYS use absolute paths. – Remy Lebeau Jul 05 '17 at 21:48
  • @IInspectable who said anything about the program being multithreaded? – Jesper Juhl Jul 05 '17 at 21:55
  • @Remy Lebeau: sure CWD can change, but that's checkable. In any case, I (personally) prefer to always use paths relative to the location of my executable. – Jesper Juhl Jul 05 '17 at 21:57
  • @JesperJuhl: Then you are not actually using *true* relative paths (paths relative to the CWD, as demonstrated in the OP's question), you are actually using absolute paths that just *happen* to use the EXE path as their prefix. – Remy Lebeau Jul 05 '17 at 22:00
  • @Remy Lebeau I know. That bit was not meant to be in relation to OPs question - just me stating my personal preference. – Jesper Juhl Jul 05 '17 at 22:03
  • @JesperJuhl: Always expect an application on Windows to be multi-threaded. The OS will create threads, and you have no control over this. Again, you cannot reliably use the current working directory in a Windows application. And there is no reason to rely on it either. If you believe otherwise, please provide a convincing use-case, for which there is no other solution. – IInspectable Jul 06 '17 at 06:40

0 Answers0