Flaviu2 wrote:
Kindly thank you for your time.
I have tested my *local HDD*, which is also NTFS, I attached the
hexdump also (hexdumpLocalHDD.txt), and I noticed that I got the
following message from Frhed app, and of course, my *HDD* NTFS is
working well.
Inline image
I have also checked the *openfile* function that read the hdd device:
_open (_open, _wopen
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-wopen?view=vs-2019>
<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/open-wopen?view=vs-2019>
)
int mode_basic = 0;
mode_basic |= O_BINARY;
mode = O_RDWR | O_EXCL | mode_basic;
hd_h = /_open(device, mode);/ // *hd_h is 3*
What do you feed into the "device" argument ?
and hd_h response had 3 value when I read my USB NTFS drive and my
local HDD NTFS drive. And the ntfs library goes on the same place:
Here is my hexdump print screen from my *USB* HDD NTFS drive:
This is clearly the full device instead of the ntfs (first) partition.
[...]
Inline image
Even if I got different messages from hex client, the ntfs client
library run the same issue ... I don't understand why ...
Why do you not just use the functions provided by ntfs-3g
(in win32_io.c) ?
Jean-Pierre
I really appreciate your help !
Flaviu.
P.S. Here is my C: drive:
Inline image
_______________________________________________
ntfs-3g-devel mailing list
ntfs-3g-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
