Fooling the disk change line

[Alt255]

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​

 

[AmkG]

In DOS there is a function call which flushes the caches and stuff like that... I presume that there is a congruent call somewhere in the Windows kernel... Try looking for undocumented stuff. Also, presumably Windows keeps those in a cache, so maybe you can try crashing the cache manually (i.e. put the changes in Window's cache, then write from the cache the way Windows would do it). Of course it's protected mode, though... "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[sarnath]

hi amkg,
can u get me the function call number in dos ?
I searched lot of undoc stuff ,but only in vain..
and what about windoze call for flusin
Do not rejoice that ur code works.
it might be a special case of an error :-(

 

[AmkG]

Int 21h Function 0dh
Reset Disk
Flushes all disk-buffer contents (if modified) to the appropriate disk files
Calling registers: AH=0dh
Return registers: none
Comments:
This function writes the contents of the disk buffers to their corresponding disk files (flushes the disk buffers). It does not update the disk directory and should not be used in place of a file-close operation. No other disk operations are affected, nor are any other disk parameters reset

On a 3Com network, this function forces a new copy of the network voume file allocation table (FAT) to be loaded into memory when all files are closed.

Int 21h Function 68h
Flush Buffer
Flushes all buffered data for a file to the device
Calling registers: Ah=68h, BX=file handle
Return registers: Carry flag=1 if error, AX=error code if carry flag set



*From DOS Programmer's Reference 4th Edition by Que Corporation

These aren't exactly what are needed in the problem, but these are what I've found so far... I think I need to read that book more carefully, I do remember seeing a function there which flushes everything and resets the buffer. Or maybe there's a procedure for it. I mean, after all, format writes a new FAT to a drive, it must be doing something that makes DOS read the FAt again... or it might not. DOS isn't as sophisticated as Windows after all, so maybe DOS stores an FAT in memory IFF a file is open. "Information has a tendency to be free. Which means someone will always tell you something you don't want to know."

 

[Alt255]

Thanks, AmkG. I'll try Int 21, function 0dh. I'm pretty sure this is the functional equivalent to Int 13, function 00h (with the exception of flushing the file buffers) but it's worth a try.

The problem with all this might be that I can't force the OS to update the FAT without changing a file. I can't change a file because the FAT would be updated incorrectly (if I change the FAT before I change the file the OS would corrupt the new FAT copy with a revised version of the old one... or so I assume).

A bit of Catch-22 here. Thanks for the research! I'm certain there is a way to do this... the procedure just isn't very straightforward.

Alt255@Vorpalcom.Intranets.com​

 

[Prattaratt]

Don't know if this will work, but I would try it:
Try Trapping INT 16H, setting the carry flag if you have changed the disk Info or continuing with original interrupt By far call if not, and returning.

 

[Alt255]

Sorry, Prattaratt. I couldn't find a way to make that work across platforms (or any platform, indeed).

I still haven't found a solution to this problem.

This isn't my usual style but I'm making an exception. If anybody has an answer to my question, or even a thoughtful comment, please post it here.

 

[sarnath]

I hope ur problem arises because of 2 OSes.If u
read and write via 1 OS, then caching
should not be a problem.
But since u r write for One OS and read
from Other, the problem persists.
Try to do both reads and writes via a single
OS. Thats the solution.
Otherwise, probablu u may need to
configure WinNT in somway, the probabltyi
is very least in this case.
The best case is read and write via the
Same OS. Thats the only possible solution, I guess

Sarnath
Do not rejoice that ur code works.
it might be a special case of an error :-(

 

[Alt255]

Thanks for the response, sarnath, but I'm not sure where you are heading with this. I am only working with one OS at a time, although I had hoped to find a way to make it work for Win9x and NT (XP might be out of the question... I haven't had an opportunity to try it).

The first part of the problem is solved. I can use Int13 under NT, bypassing the HAL, and reading or writing to the physical disk sectors. This isn't a problem: I can modify the boot sector and FAT... subsequent reads, using Int13, show that the changes were made. But Windows is a bit slow in recognizing the changes. It doesn't accept the new disk contents until I have physically switched disks. I need to fool the OS into believing it is looking at a different disk, even though it is simply accessing a modified version of the same disk.