_open generate "Access is denied" error
-
Confidence that I have solved all strange errors here, I come back with some issue generated by a legacy C code for linux, code that I intend to use it in a MFC app in windows OS. Ok. I have a simple code:
int nRespond = _open(device, 020);
UINT err = ::GetLastError();where devide is const char* and has value C (or D:, or E: ) The nRespond is -1 and err has value 5, which is mean
Access is denied
. What could be the problem here ? I ran the test app as administrator mode (ran from VS2017 as admin mode). -
Confidence that I have solved all strange errors here, I come back with some issue generated by a legacy C code for linux, code that I intend to use it in a MFC app in windows OS. Ok. I have a simple code:
int nRespond = _open(device, 020);
UINT err = ::GetLastError();where devide is const char* and has value C (or D:, or E: ) The nRespond is -1 and err has value 5, which is mean
Access is denied
. What could be the problem here ? I ran the test app as administrator mode (ran from VS2017 as admin mode).Your flags (020) are linux flags not windows try ( _O_WRONLY | _O_CREAT ) or some normal windows flags _open, _wopen | Microsoft Docs[^] I would add even in linux the code really should be written as flags not a value like that for this exact reason.
In vino veritas
-
Your flags (020) are linux flags not windows try ( _O_WRONLY | _O_CREAT ) or some normal windows flags _open, _wopen | Microsoft Docs[^] I would add even in linux the code really should be written as flags not a value like that for this exact reason.
In vino veritas
-
You cannot access raw devices on Windows by their drive letters, you must use their volume identifiers. See File path formats on Windows systems | Microsoft Docs[^].
-
Your flags (020) are linux flags not windows try ( _O_WRONLY | _O_CREAT ) or some normal windows flags _open, _wopen | Microsoft Docs[^] I would add even in linux the code really should be written as flags not a value like that for this exact reason.
In vino veritas
-
I also tried this:
#include int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{\_open("D:", 0x02 | 0x04); UINT e = ::GetLastError(); cout << e;
}
from cmd line as administrator rights … the same result: 5 (access is denied).
Big Errors You can't open "D:" that isn't a file ... its not linux you don't mount drives Try
int nRespond = _open("D:\\somefilename.txt", _O_WRONLY | _O_CREAT);
UINT e = ::GetLastError();I am sure it will open :-)
In vino veritas
-
Big Errors You can't open "D:" that isn't a file ... its not linux you don't mount drives Try
int nRespond = _open("D:\\somefilename.txt", _O_WRONLY | _O_CREAT);
UINT e = ::GetLastError();I am sure it will open :-)
In vino veritas
-
I get this code from a plain C code which has built for Linux:
int nRespond = _open(device, 020);
-
You cannot run Linux code on Windows without adjusting it for the differences. Windows does not let you address raw devices in the same way that Linux does. And in fact doing so is very dangerous as you could destroy your entire system.
-
And is any other method to open a device rather than _open in Windows ? I think I have to made some changes into Linux code to run on Windows ...
-
Agree. Is there any windows methods to open a disk and get the handle ? Because this nResponse it is used further as a handle ...
Yes. It is [CreateFile function (fileapi.h) | Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)
-
Yes. It is [CreateFile function (fileapi.h) | Microsoft Docs](https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea)
-
Good idea. I have used CreateFileA, and I get rid of that "access denied". But there a thing that I had afraid: the original code, with _open returned int, and CreateFileA return HANDLE ... casting HANDLE to int is OK ? I guess not ...
How are you going to use the handle returned from _open ?
-
Good idea. I have used CreateFileA, and I get rid of that "access denied". But there a thing that I had afraid: the original code, with _open returned int, and CreateFileA return HANDLE ... casting HANDLE to int is OK ? I guess not ...
Windows has GetLastError you notice CreateFile Simply returns invalid handle for an error if you get that then you call GetLastError GetLastError function (errhandlingapi.h) | Microsoft Docs[^] That is the equivalent of your original int it's just a non zero number identifying the error, 0 always equals no error.
In vino veritas