Is there any way to know for sure if I accessed alright the NTFS drive ?
(Which is in fact an USB drive)
To eliminate this problem once ...
On Friday, April 10, 2020, 07:00:05 PM GMT+3, Flaviu2 via ntfs-3g-devel
<[email protected]> wrote:
I guess I succeeded into reading the NTFS drive with this approach:
"\\\\?\\E:"
ran as admin mode.
But I guess the issue is a little bit earlier. Let see the code, in device.c
file
ntfs_volume* ntfs_volume_startup(struct ntfs_device *dev, ntfs_mount_flags
flags){....... // Now read the bootsector.
br = ntfs_pread(dev, 0, sizeof(NTFS_BOOT_SECTOR), bs); if (br !=
sizeof(NTFS_BOOT_SECTOR)) { if (br != -1) errno = EINVAL; if (!br)
ntfs_log_error("Failed to read bootsector (size=0)\n"); else
ntfs_log_perror("Error reading bootsector"); goto error_exit; } // here
is my issue, that told me: NTFS signature is missing.
if (! ntfs_boot_sector_is_ntfs(bs)) { errno = EINVAL; goto error_exit; }
I suspect that ntfs_read function is reading ok my NTFS drive. Because in
ntfs_boot_sector_is_ntfs is done only this verification:
if (b->oem_id != const_cpu_to_le64(0x202020205346544eULL)) // "NTFS "
....
So, inside ntfs_read function, I have:
s64 ntfs_pread(struct ntfs_device* dev, const s64 pos, s64 count, void* b){...
dops = dev->d_ops;
The line from above, dops = dev->d_ops;, I didn't understand ... .what does it
? Can you tell me ? I guess is assigned some functors from dev->d_ops to dops ?
But where is those dev->d_ops functions, if my assumptions are correct ?
I really appreciate your time and help !!!
Regards,Flaviu.
On Monday, March 16, 2020, 10:41:48 AM GMT+2, Jean-Pierre André
<[email protected]> wrote:
Flaviu2 via ntfs-3g-devel wrote:
> "You are unlikely to be able to access the system partition
> C: in read-write exclusive mode, this obviously conflicts
> with system access.
>
> Also low-level opening of a partition is done with the
> prefix \??\ which you might try."
>
> My code looks like that:
>
> /hd_h = _open("*\\\\.\\C:*", mode);/
>
> I have tried a lot of combination with "*\??\*", but *hd_h* retunrn
> always -1, which reveal that formatting was not ok. Please tell me what
> kind of formatting I can try, just write me the first parameter from
> *_open* function.
>
> I have tried:
>
> "\\??\\\\\\.\\C:" and so on ... nothing worked, but perhaps I didn't
> understood something ...
Again : You are unlikely to be able to access the system partition
C: in read-write exclusive mode, this obviously conflicts with
system access.
> > I haven't used win32_io.c file ... would help me to solve my issue ?
> > Since the actual code read the drive ...
>
> This might be a possible way, unless you have some specific need...
>
> Yes, I can try anything, but exploring that source code, I only saw that
> is accessing hdd drive with:
>
> CreateFile("\\\\.\\PhysicalDrive0", ...)
>
> which I also tried, and *hd_h* return 3, but the somehow the drive is
> not recognized as NTFS, but exfat or fat32 ... anyway, I need to access
> the drives not as physical drive but as logical drive (C:, D:, and so on.)
I meant using the function ntfs_device_win32_open() with
an argument like X: with no prefix and X different from C,
though this might not match your needs.
> Thank you for your time and help !!! Please tell me how to overcome this
> issue.
This is a Windows issue, not an ntfs one. A windows oriented
mailing list might be more suitable.
Jean-Pierre
>
> Flaviu.
>
>
>
> On Monday, March 9, 2020, 10:52:33 PM GMT+2, Jean-Pierre André
> <[email protected]> wrote:
>
>
> Flaviu2 wrote:
> > 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:
>
> You are unlikely to be able to access the system partition
> C: in read-write exclusive mode, this obviously conflicts
> with system access.
>
> Also low-level opening of a partition is done with the
> prefix \??\ which you might try.
>
> > I haven't used win32_io.c file ... would help me to solve my issue ?
> > Since the actual code read the drive ...
>
> This might be a possible way, unless you have some specific need...
>
> Jean-Pierre
>
>
> >
> > Regards,
> > Flaviu.
> > On Monday, March 9, 2020, 10:59:31 AM GMT+2, Jean-Pierre André
> > <[email protected]
> <mailto:[email protected]>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
