Is there a way in VB to read the Hard Drive by sector and not file? There is obviously a way in one language (probably C because it is more low-level) because of programs like Disk Defragmenter etc...
You may be able to find API calls that achieve this but if you're not careful you'll end up screwing your FAT tables up and making the drive inaccesible!
If you look at www.vbapi.com you may find the API calls.
'Buzby'
Visual Basic Developer "I'm moving to Theory. Everything works there."
i'm passing along info someone else gave me in another forum. I had the same question (i'm trying to convert a dos program i wrote to windows). The following text is taked from msdn:
INFO: Direct Drive Access Under Win32
--------------------------------------------------------------------------------
The information in this article applies to:
Microsoft Win32 Application Programming Interface (API), used with:
The Microsoft Windows NT operating system, versions 3.1, 3.5, 3.51, 4.0
The Microsoft Windows 2000 operating system
SUMMARY
To open a physical hard drive for direct disk access (raw I/O) in a Win32-based application, use a device name of the form
\\.\PhysicalDriveN
where N is 0, 1, 2, and so forth, representing each of the physical drives in the system.
To open a logical drive, direct access is of the form
\\.\X:
where X: is a hard-drive partition letter, floppy disk drive, or CD-ROM drive.
MORE INFORMATION
You can open a physical or logical drive using the CreateFile() application programming interface (API) with these device names provided that you have the appropriate access rights to the drive (that is, you must be an administrator). You must use both the CreateFile() FILE_SHARE_READ and FILE_SHARE_WRITE flags to gain access to the drive.
Once the logical or physical drive has been opened, you can then perform direct I/O to the data on the entire drive. When performing direct disk I/O, you must seek, read, and write in multiples of sector sizes of the device and on sector boundaries. Call DeviceIoControl() using IOCTL_DISK_GET_DRIVE_GEOMETRY to get the bytes per sector, number of sectors, sectors per track, and so forth, so that you can compute the size of the buffer that you will need.
Note that a Win32-based application cannot open a file by using internal Windows NT object names; for example, attempting to open a CD-ROM drive by opening
\Device\CdRom0
does not work because this is not a valid Win32 device name. An application can use the QueryDosDevice() API to get a list of all valid Win32 device names and see the mapping between a particular Win32 device name and an internal Windows NT object name. An application running at a sufficient privilege level can define, redefine, or delete Win32 device mappings by calling the DefineDosDevice() API.
-If you manage to get a working piece of code after reading all of this, let me know. I am unfamiliar with both of the api calls they mention here.
Buzby, I've been to that site (VBAPI) and so far it has nothing on reading sectors.
Lord Orwell, I understand what you have written but I cannot get it to work. I have put all the API calls into a program a fiddled around a while but I cannot read any sector or any byte of any drive. It doesn't do anything.
Even if I do manage to get it working, and I have a non FAT16 or FAT32 drive (maybe a Linux partition or something, I dunno, just one that Windows can't read) and I shove it into my computer, using that API call wouldn't I be able to get the data off the hard drive? It's a bit like those CD Copiers that can copy copyrighted CDs, they read the CD sector by sector, so I thought it might work with hard drives.
I don't fully understand the bulletin, but i do know that you have to use both the FILE_SHARE_READ and FILE_SHARE_WRITE flags at the same time, not separately.
If i was to try to open the hard drive as a file (returning the hard-drive handle), i would do this:
DrvHndl=CreateFile ("\\.\C:", GENERIC_READ + GENERIC_WRITE, FILE_SHARE_READ + FILE_SHARE_WRITE, lpSecurityAttributes, OPEN_EXISTING, ByVal FILE_FLAG_NO_BUFFERING, 0&)
Try these flags and tell me if it works.
The reason i haven't tried this myself, is i haven't ever used the api calls for file operations. I might open the hard disk correctly, and incorrectly read , etc. I need to get some pre-done code to examine.
I saw at the VBAPI site that only Windows NT and 2000 can read from the drive directly. Bummer because I have Windows 98. Getting 2000 soon though.
So far I have the following code:
Code:
Public Function ReadDrive(BytesToRead As Long)
Dim dh As Long
Dim strBuffer As String
Dim lngRead As Long
dh = CreateFile("\\.\D:", GENERIC_READ + GENERIC_WRITE, FILE_SHARE_READ + FILE_SHARE_WRITE, ByVal CLng(0), OPEN_EXISTING, ByVal FILE_FLAG_NO_BUFFERING, 0)
If dh = -1 Then
MsgBox "Could not open drive D:"
End
End If
strBuffer = Space(BytesToRead)
ReadFile dh, strBuffer, Len(strBuffer), lngRead, 0
ReadDrive = strBuffer
End Function
The reason I am using drive D is because that is a secondary backup hard drive (sort of like a mirror). Anywho, that code does not appear to work (maybe because I am using W98). dh always appears to be -1.
Um, i assume that you declared all of the constants, such as FILE_SHARE_READ? I ask merely because they aren't in your code sample. I will try to get your code to work. From what i understand though, after you get it to work, you have to set strbuffer to the length of a sector. I don't know if they mean physical sector (512 bytes) or logical sector(2048 bytes under fat-32). I would assume they mean physical sector though. That is how the dos version of this call works.
Last edited by Lord Orwell; Feb 20th, 2001 at 11:42 PM.
Yes, I did have all the constants. So far, BytesToRead can be set to anything, mainly because it can't get past the first step of geting a handle to the drive.
I thought the amount of Bytes Per Sector (BPS???) is different depending on what hard drive you have, or maybe that is Sectors Per Cluster, or Bytes Per Cluster.... I dunno, I get confused, but anyway, it definately is different.
Check out the attachment... it is just a small program I made when I first learned API.
Whoops, the way I said it made it look like I was always right (where I said "it is definately different"). What I meant to say was "something is definately different (depending on your hard drive)".
Well i was perusing the microsoft Developers Network, and their main entry (not the one i was shown before) clearly states that the direct disk operations only work on the nt/2000 oses.
But that still doesn't make any sense. Windows NT/2000 are supposed to have higher security levels than Windows 98 (or 95). So what really bothers me is that direct disk operations is a security breach, and therefore, shouldn't be available in Windows 2000, and just in Windows 95/98 or not at all.
Microsoft does some pretty dumb things, especially making Windows 2000 look less 'securitised' than Windows 98 when it comes to disk operations.
Also I heard that Windows 2000 is just NT5 but a lot of people say it is Windows NT4 combined with Windows 98, which sounds like bull****.
If you don't have root access, the function will fail (see original post)
Win 2000 is NT5. The user interface has been enhanced to resemble win 98/me. But it only RESEMBLES it.
I almost forgot. I found out how all those other programs are writing to and from sectors.
They are using custom .VXDs There is information on creating them on the msdn, and i believe a program for compiling them.
Reply With Quote
