Disk Change Line

[Alt255]

This is my first question in the Qbasic forum. (It was inevitable.)

I asked the following question in the Assembly forum a few months ago but didn't receive an answer I thought I could use. I am using QB4.5, trying to perform the following:[tt]

My application uses Interrupt 13, functions 2 and 3 to read and modify the boot sector and FAT entries on a disk to allow or prevent access to some or all of the files. I'm not using Assembly but the basic principles should remain the same and I hope that one of the gurus in this forum can help me.

In a nutshell, I am using a Visual Basic front-end that accepts a password and shells to a DOS app that uses the password to perform a little low-level magic on a disk (e.g. encrypts the FAT or marks the disk as "unformatted" or marks certain files as "deleted" or simply encrypts the disk sectors based on the password - I'm still working with floppies, only, since NT is a bit fussy about direct access to the hard drives.). All of this has worked quite well on floppy disks (no BSODs)... with a minor glitch: Changes to the disk are not immediately apparent because the disk contents are cached by the OS. The only way to view the changes is to access a different disk and then access the original disk again.

Does anybody know of a way to reset the disk change line to fool the OS into believing that the disk has been switched without actually switching disks? I have tried every trick I can think of but it appears that Windows always relies on the original contents of the disk, based on the first access, even after the FAT entries have been hopelessly scrambled... and doesn't bother to look at the changed FAT until the disk is swapped with another.[/tt]

There are some real gurus lurking in these threads. Come out of the shadows and lend me a hand, please.

 

[Guest_imported]

Since you're bypassing the NT HAL, I don't know if this will work, but try running Sync.

http://www.sysinternals.com/ntw2k/source/misc.shtml#Sync

That might make NT flush its disk cache, and give you the correct newly written data from the disk.

 

[Alt255]

Thank's for the reply, Toshi. I will take a look at it.

Really, I had hoped to perform the same task without using another utility.

Any idea how Sync performs the flush under Win9x?

 

[Alt255]

Ahhh... never mind... the Sync utility just uses the standard APIs (including FlushFileBuffers). I'm pretty sure I can't use this approach because it would corrupt the contents of the disk.

For example: let's say the user selects options to make the disk appear to be unformatted (this zeroes the "total sectors" field and makes a few other changes in the boot record) and make the FAT chain untraceable (this uses substitute encryption on the table of root directory entries using a value calculated from the password). All of this works very well.... writing changes to the disk and verifying them requires about three seconds (on a floppy). The disk is unreadable in another machine. Access a different disk in the original machine and then access the FAT encrypted disk... it is unreadable. Run my app, enter the password, undo the encryption, access a different disk, access the unencrypted disk... and it has been restored to it's original condition.

The problem with simply flushing the file buffers is that the OS would try to update the scrambled FAT with portions of the original FAT. Any attempt to unencrypt the disk with the password would fail. The same applies to Int 21h, function 68h (commit file) and Int 21h, function 5Dh, subfuntion 01h (commit files for process).

Windows maintains a field in the disk boot record formerly reserved for the OEM ID (this used to identify the OS or utility that originally formatted the disk). Windows writes a string in this field and saves that value the first time the disk is accessed. This is one of the ways Windows determines whether or not a disk has been replaced (if you have ever seen a blue screen that commands you to "Insert Volume XXXX:XXXX in Drive X: to Continue", you have probably seen an example of the confusion created when Windows reads the OEM ID field and finds something it didn't expect. My experimentation with the values in this field (using Int 13) suggest that Windows also relies on a different method to detect disk changes. A modification of the OEM ID followed by a "standard" disk access doesn't force Windows to assume that the disk has been changed. I think Windows uses Int 13h, function 16h to detect the change.

Crap... there doesn't appear to be a corresponding function to force recognition of a disk change. I assume the BIOS maintains some sort of flag near the beginning of RAM, indicating the status of the various disks, but I haven't been able to isolate it and I seriously doubt that I could fool Windows by simply poking a byte or two. Whatever mechanics are involved here, they appear to be completely undocumented.

Nevertheless, I am persistant. There must be a way show the OS that the physical contents of a disk have changed without allowing the OS to write to the disk.

To answer the inevitable question: "Why are you trying to do this with Quick Basic?" It appears that QB is one of the few tools that allow this sort of thing without triggering access violations and numerous other errors. One of the experts in another forum tried to convert some similar code to various 32-bit languages with hopes of storing the functionality in a DLL for use by other apps. It absolutely would not work... no matter what he tried. he was quite frustrated that the sample EXE and QB source code I sent him worked perfectly under Win9x and NT but that he could not duplicate the effects in any other language. His last communication (before he curled up in a fetal position to contemplate the meaning of life) complained that QB appeared to use "16-bit thunking" (I have only a dim awareness and understanding of this concept).

I hope this explains what I am trying to accomplish a little better. Any ideas would be appreciated but, please note, I would like to keep the functionality contained in my own application.