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.
Alt255@Vorpalcom.Intranets.com
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.
Alt255@Vorpalcom.Intranets.com