Hi guys,
When there is open handles in a volume, windows format asks to “force the
format”. In this case, handles become invalid, how does OS do this? When I
call WriteFile with such handles, I do see it constructs an IRP and call
IoCallDriver, but my minifilter cannot intercept it.
Does anyone know the internals?
Thanks
Herb
I would trace that IRP call till VPB check.
Aditya
>When there is open handles in a volume, windows format asks to “force the format”. In this case,
handles become invalid, how does OS do this?
Format (as also chkdsk /f) locks the volume.
If lock succeeds - normal case, no open files on format - then dismount follows the lock, which detaches the FS’s VolDo with all its stuff from the block volume stack.
Then the last handle (used by “format”) is still alive enough to do DASD writes do the volume, which write the new FS (or correct the existing one in case of chkdsk).
The the last handle is closed, this destroys the already detached FS’s VolDo and its stuff.
On next file open on this volume, Windows auto-mounts the new FS’s VolDo during pathname parsing.
Now what if there are open handles on lock. Then lock fails, and the “format” tool prints “do you want to force dismount”? if you say “yes”, then it does dismount without preceding lock.
This dismount does the same (i.e. detaches the FS’s VolDo), but also switches all existing FOs on this FS’s VolDo to some “dead” mode, in which all IO on them fails.
The details are in FASTFAT source. I think the first call inside FAT’s paths is FatDecodeFileObject, which will fail in a proper way if the volume is dismounted/detached.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
I know that in our own file systems work, our Fcb (or Scb if you prefer the NTFS terminology) points to it’s Vcb (“volume control block”). When you force dismount a volume, what happens is that MediaDeviceObject->Vbp is swapped with a new Vpb (I say “new” but in fact the right time to allocate that Vpb is at volume mount time, since cleanly recovering from an allocation failure during dismount is challenging and other system components get VERY unhappy if you fail the forced dismount).
Thus, MediaDeviceObject->Vbp->DeviceObject (the mounted file system) doesn’t point to the same thing any longer. For us, this is the “volume control block” (for media file systems).
New file objects point to the new Vpb (FileObject->Vpb) and old file objects point to the old Vpb. Thus, FileObject->Vbp->DeviceObject points to our Vcb structure. In that Vcb structure we maintain a field called VolumeDismounted, which is TRUE if the underlying volume has been dismounted.
Effectively any I/O operations sent to our FSD then fail. We continue to process cleanup and close of course, but what usually happens is that an application performs an I/O, we fail it, the application terminates and the I/O Manager cleans up all their open handles. Eventually all the references to the Vcb go away and we deallocate it.
FAT does something similar, but it is a bit more complicated because FAT has a model of “remounting” that most file systems just skip. Here’s the scenario: imagine you were on E-Bay and saw this ancient I/O device called a “floppy disk” and you bought one and connected it to your computer. Windows gladly will support said floppy disk and (assuming you also bought media) has this interesting behavior: it will permit you to access TWO different floppy disks (A: and B: are still reserved for those two floppies even today) - but using ONE physical drive. So as you switch floppies, FAT dismounts one volume and then “remounts” the other one. Back and forth it goes. Ah yes, I remember using two virtual floppies on a machine with one physical floppy - back in 1981.
Thus, the FAT example here is in some ways more complicated (and different) than the other file systems. NTFS doesn’t have to worry about floppies and I’m sure that the ReFS folks didn’t suddenly get floppy fever. On the other hand, at least one of the people involved in the ExFAT implementation was involved in the FAT implementation so maybe it DOES handle them… still, I doubt it.
The CDFS example will also show you a different implementation model. They used to do something akin to remount but found it doesn’t work with CDs (something about people burning an additional session onto an existing CD).
Tony
OSR