CD insert/remove

In my upper volume filter, how can I find out where a CD is
inserted/removed? I want to know this because I maintain per CD
performance information, which must be allocated/deallocated that time.
What IRPs are sent?

Another thing: is there a way to purge the cache maintained for a CD, at a
given moment?

TIA,
Razvan

Mount and verify (for remount) IRPs are sent.

Max

----- Original Message -----
From: “Razvan Hobeanu”
To: “File Systems Developers”
Sent: Saturday, March 15, 2003 12:21 AM
Subject: [ntfsd] CD insert/remove

> In my upper volume filter, how can I find out where a CD is
> inserted/removed? I want to know this because I maintain per CD
> performance information, which must be allocated/deallocated that
time.
> What IRPs are sent?
>
> Another thing: is there a way to purge the cache maintained for a
CD, at a
> given moment?
>
> TIA,
> Razvan
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Thank you for your quick reply!

So what exactly are those IRPs? And can any read be made between the time
the CD was inserted and the time they occur?

TIA,
Razvan

> So what exactly are those IRPs? And can any read be made between the
time

the CD was inserted and the time they occur?

They relate to FS mount. A rather long story (I spent a day last
summer to study the details), I will describe this in brief.

If the FSD during its work hits the situation where it is suspicious
whether the media was changed, it calls IoVerifyVolume. This one sends
the verify IRP, calling the FSD’s verify path. The verify path does
some reads from the media to identify it (for FAT, it is BPB+serial
number+the volume label, forgot the CDFS’s identification data) and
then either tears the volume away to “dismounted” state on mismatch,
or continues the normal operation on match.

If the volume was torn down - then new file opens will trigger another
mount. So, several FS volumes - one active and many “dismounted” - on
the same block device.

“Dismounted” volume lives till all its files will close. The mount
path starts with reading the identification data from the media, and
then traversing the list of “dismounted” volumes, looking for a match.
If the match is found - then the “dismounted” volume is resurrected
back to active state, for FAT this implies re-reading the FAT tables
and rebuilding the allocation bitmap.

So, the app which keeps some files on removable media as open for long
time will survive media changes, if the original media will return
back sooner or later. This is contrary to the UNIX approach which
requires remount from the command line or by the service, and dismount
fails in the presense of the open files.

For details, look at DO_VERIFY_VOLUME stuff in block device driver
(CdRom/ClassPnP) source from the DDK, and at mount/remount/verify
paths in FASTFAT and CDFS sources from the IFS kit.

Yes, raw FS-less reads can be done bypassing these IRPs, but they are
not possible from user mode anyway - any attempt to open, say, “Z:”
will result in a mount, unless the open is with READ_ATTRIBUTES access
which prohibits reads from this handle.

Max

Since the filter is an upper class filter for the CD-ROM class, I don’t
have access to volumes or something else. And I’m not interested in
volumes.
What I want to do is to count the IRP_MJ_READs made for every CD inserted
so it is important for me to make the difference between CDs and to know
when they
are inserted, before any read occurs.
I checked IOCTL_STORAGE_CHECK_VERIFY but this didn’t help me. I wonder if
there is a way to know when the CD is inserted, just like the I/O Manager
“sees” that and starts the file system recognizers.

Is there something wrong with the place where my filter is? How can I
detect
that insertion? IOCTL_STORAGE_CHECK_VERIFY didn’t help since I see reads
during system boot before any IOCTL_STORAGE_CHECK_VERIFY occurs.

TIA,
Razvan

They relate to FS mount. A rather long story (I spent a day last
summer to study the details), I will describe this in brief.

If the FSD during its work hits the situation where it is suspicious
whether the media was changed, it calls IoVerifyVolume. This one sends
the verify IRP, calling the FSD’s verify path. The verify path does
some reads from the media to identify it (for FAT, it is BPB+serial
number+the volume label, forgot the CDFS’s identification data) and
then either tears the volume away to “dismounted” state on mismatch,
or continues the normal operation on match.

If the volume was torn down - then new file opens will trigger another
mount. So, several FS volumes - one active and many “dismounted” - on
the same block device.

“Dismounted” volume lives till all its files will close. The mount
path starts with reading the identification data from the media, and
then traversing the list of “dismounted” volumes, looking for a match.
If the match is found - then the “dismounted” volume is resurrected
back to active state, for FAT this implies re-reading the FAT tables
and rebuilding the allocation bitmap.

So, the app which keeps some files on removable media as open for long
time will survive media changes, if the original media will return
back sooner or later. This is contrary to the UNIX approach which
requires remount from the command line or by the service, and dismount
fails in the presense of the open files.

For details, look at DO_VERIFY_VOLUME stuff in block device driver
(CdRom/ClassPnP) source from the DDK, and at mount/remount/verify
paths in FASTFAT and CDFS sources from the IFS kit.

Yes, raw FS-less reads can be done bypassing these IRPs, but they are
not possible from user mode anyway - any attempt to open, say, “Z:”
will result in a mount, unless the open is with READ_ATTRIBUTES access
which prohibits reads from this handle.

> I checked IOCTL_STORAGE_CHECK_VERIFY but this didn’t help me. I
wonder if

there is a way to know when the CD is inserted

This is not enough for you. You must distinguish between “the same CD
reinserted” and “new CD inserted” situations, and this is impossible
without CDFS help.

Max