How autochk determines that ntfs-volume is in use?

NTFSD
1

Hello, all.

My FS filter driver creates/opens on each volume own data-base file. It starts early and creates database as soon, as it attaches to the volume. So problem is with chkdsk. When windows is already loaded and I manualy run checkdisk with enabled checkbox “automaticaly fix file system errors” my filter receives FSCTL_LOCK_VOLUME so I can close my database file and disk checking will succeed. But in some cases disk-checking is sheduled for next reboot. I noticed that after rebooting if disk checking is sheduled for NTFS volume, FSCTL_LOCK_VOLUME does not come to me, and message “Cannot open volume for direct access” apears, but for FAT32 volume - it comes.

I can analyze registry HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute , but at that case user can refuse disk-checking and my actions will be needless and bases will be not opened. So I do not like this solution.

So, my question is: How autochk determines that ntfs-volume is in use?
And are there any ideas relatively my problem?

2

When does your FS filter load? You wouldn’t see autochk (for example) if your filter loads after the NTFS volume has been checked.

Besides the lock volume call, there’s no other mechanism for an application to determine if the volume can be taken offline (e.g., for autochk) so it suggests you are missing the check, not that the check isn’t happening. If you really want to verify this, I’d suggest setting a breakpoint in the FSCTL handler for NTFS right as the system starts up and then checking to see if you can observe when that lock volume is arriving - from there I suspect you’ll be able to figure out why you are missing it.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

3

>that after rebooting if disk checking is sheduled for NTFS volume,

FSCTL_LOCK_VOLUME does not come to me, and message “Cannot open
volume for direct access” apears, but for FAT32 volume - it comes.

Maybe this is due to hidden data files in “System Volume Information” folder
VolSnap uses for snapshots? They are often opened in the mount path itself, so,
any lock of such volume will fail.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Hello.
Thanks for your answers.

When does your FS filter load?

My FS Filter is loads-start type is “1”, so it loads early. Yes you are right about later start, but it is interesting to view other variants.

If you really want to verify this, I’d suggest setting a breakpoint in
the FSCTL handler for NTFS right as the system starts up and then
checking to see if you can observe when that lock volume is arriving -
from there I suspect you’ll be able to figure out why you are missing
it.

I see some FSCTL in autochk process context: FSCTL_ALLOW_EXTENDED_DASD_IO and FSCTL_IS_VOLUME_DIRTY (a few times) . Are they things, I need?
I suppose, that not. BTW, FSCTL I need to handle shuold come via my filter (I attach it to all volumes and file systems I can find).

Maybe this is due to hidden data files in “System Volume Information” folder
VolSnap uses for snapshots? They are often opened in the mount path itself, so,
any lock of such volume will fail.
No, I create some files by myself and I want to handle a situation when I should not do it.

Best regards,

Alexey Barabash

5

You are seeing problems because you are not handling an “implicit” lock
request which is how autochk (chkdsk at boot time) locks the volume.
You will not see a lock volume fsctrl. Instead you will see a volume
open where it is requesting exclusive access to the volume. This is
called an “implicit volume lock”. Functionality wise it works exactly
the same as an explicit volume lock.

If you look at the “Meta Data Manager” sample in the latest IFS Kit or
WDK it shows you what a minifilter needs to do for lock & dismount
operations if it has a private metadata file. The principles work for
legacy filters as well. Any one developing a filter which has a private
metadata file should review this sample to make sure they are following
all of the rules.

Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, October 12, 2006 12:12 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How autochk determines that ntfs-volume is in use?

Hello.
Thanks for your answers.

When does your FS filter load?

My FS Filter is loads-start type is “1”, so it loads early. Yes
you are right about later start, but it is interesting to view other
variants.

If you really want to verify this, I’d suggest setting a breakpoint in

the FSCTL handler for NTFS right as the system starts up and then
checking to see if you can observe when that lock volume is arriving -

from there I suspect you’ll be able to figure out why you are missing
it.

I see some FSCTL in autochk process context:
FSCTL_ALLOW_EXTENDED_DASD_IO and FSCTL_IS_VOLUME_DIRTY (a few times) .
Are they things, I need?
I suppose, that not. BTW, FSCTL I need to handle shuold come via my
filter (I attach it to all volumes and file systems I can find).

Maybe this is due to hidden data files in “System Volume Information”
folder
VolSnap uses for snapshots? They are often opened in the mount path
itself, so,
any lock of such volume will fail.
No, I create some files by myself and I want to handle a
situation when I should not do it.

Best regards,

Alexey Barabash

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com