When is IRP_MJ_CLOSE called?

NTFSD
1

Hi!

I understand that an FCB represents a file stream, with a CCB representing an opened instance of that file. The same FCB is stored in however many FileObject instances have the file opened, each with its own unique CCB. I also understand that IRP_MJ_CLOSE is called after A) all app handles are closed (when cleanup is called of course), and then B) when all references in the OS are done using it. How is B) determined, and what does the FSD do to influence this decision? I don’t see what shared fields in the FCB would do it, or for that matter how a count is maintained at all. The FSD keeps a count of open files, like UncleanCount in the FastFat example code. And as I look at the FastFat example code, it seems clear that a Close can happen multiple times-is this true? Of course each Close would then destroy the associated CCB instance, and then when all the CCB instances are finally destroyed, at that point we blow away the FCB. So do then the number of Create calls that result in new CCBs match the number of Close calls to remove same CCBs? And so we can therefore get an IRP_MJ_CLOSE while we still have active CCBs, like for paging? And when people talk here about waiting to get an IRP_MJ_CLOSE, they are talking about the final one that frees up the FCB, and not the more general case of getting one really whenever a CCB is to be freed up (which if the last outstanding then results in the FCB getting deleted as well)?

Thanks!

Steve

2

>called of course), and then B) when all references in the OS are done using
it.

How is B) determined, and what does the FSD do to influence this decision? I
don’t see what shared fields in the FCB would do it, or for that matter how a
count
is maintained at all.

File object has this count in its object header, and FCB has a private per-FSD
FileObjectCount.

code. And as I look at the FastFat example code, it seems clear that a Close
can
happen multiple times-is this true?

Close is a destructor for a file object, and thus only sent once for a file
object, though maybe several times for an FCB - once per file object.

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

3

Each opened instance of the file has its own FILE_OBJECT. For given FILE_OBJECT you always get IRP_MJ_CREATE, IRP_MJ_CLOSE and usually IRP_MJ_CLEANUP. You don’t get cleanup in case some filter has called IoCancelFileOpen() or FltCancelFileOpen(). When last handle !!for given FILE_OBJECT!! is closed, FSD gets IRP_MJ_CLEANUP. Note that multiple handles to the same FILE_OBJECT you can get by handle duplication, not by opening/creating of file by xxCreateFile() like functions. FSD usually in IRP_MJ_CLEANUP dispatch routine tries to make Cache Manager and/or Memory Manager to release all references to FILE_OBJECT, so it gets IRP_MJ_CLOSE. API for it is CcPurgeCacheSection(), MmFlushImageSection(). Note that purging might not be successful in case an application keeps handle to the mapped file which is being purged.

-bg

4

>IRP_MJ_CLEANUP. You don’t get cleanup in case some filter has called

IoCancelFileOpen() or FltCancelFileOpen(). When last handle !!for given

IoCancelFileOpen IIRC sends MJ_CLEANUP

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