This time I've tested my C: drive, which is also a NTFS drive, of course, with exactly the same result. And I read what I have feed in "device" argument: "What do you feed into the "device" argument ?" \\.\C:
I haven't used win32_io.c file ... would help me to solve my issue ? Since the actual code read the drive ... Regards,Flaviu. On Monday, March 9, 2020, 10:59:31 AM GMT+2, Jean-Pierre André <jean-pierre.an...@wanadoo.fr> wrote: 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
