Detach from Cdfs file system

Dear NTFSD members,

I have a legacy filter that attached to CD/DVD filesystem.
When DVD is removed from the tray sometimes cdfs file system with my filter doesn’t detach from CDROM device. Sometimes objects are destroyed with big delay.

Sometimes I can see the following:

  1. Disk1 iserted
  2. My filter is attached
  3. Disk1 removed (FSO and filter is not destroyed )
  4. Disk2 inserted (old FSO and filter is attached to this disk)
  5. Explorer shows content of Disk1 instead of Disk2, files can’t be read.

Questions:

  1. How can I avoid this?
  2. How and when can I detach correctly?
  3. Maybe there is a reliable way to know that another DVD disk was inserted or removed? (At least I have to disable on-fly-decryption once disk is removed or another disk inserted).

Thanks in advance.

You need to filter for the fsctl IRP_MN_VERIFY_VOLUME

I thought that there was an example but there isn’t. AFAIR if this fails
then you have to do a FltDetach in the post op path…

wrote in message news:xxxxx@ntfsd…
> Dear NTFSD members,
>
> I have a legacy filter that attached to CD/DVD filesystem.
> When DVD is removed from the tray sometimes cdfs file system with my
> filter doesn’t detach from CDROM device. Sometimes objects are destroyed
> with big delay.
>
> Sometimes I can see the following:
> 1. Disk1 iserted
> 2. My filter is attached
> 3. Disk1 removed (FSO and filter is not destroyed )
> 4. Disk2 inserted (old FSO and filter is attached to this disk)
> 5. Explorer shows content of Disk1 instead of Disk2, files can’t be read.
>
> Questions:
> 1. How can I avoid this?
> 2. How and when can I detach correctly?
> 3. Maybe there is a reliable way to know that another DVD disk was
> inserted or removed? (At least I have to disable on-fly-decryption once
> disk is removed or another disk inserted).
>
> Thanks in advance.
>

Rod,

thank you, I thought about it, sometimes I can see IRP_MN_VERIFY_VOLUME fsctl, but not always.

Are there any other ways?

I have never quite understood what role FltMgr plays in this space since
there is also the puzzling psuedo-major code “IRP_MJ_VOLUME_DISMOUNT”, and
there is evidence in the context tear down API that at one stage during the
design process it was assumed that the FltMgr would do the work for you.

However, watching IRP_MN_VERIFY_VOLUME has always been sufficient for me…

Rod

wrote in message news:xxxxx@ntfsd…
> Rod,
>
> thank you, I thought about it, sometimes I can see IRP_MN_VERIFY_VOLUME
> fsctl, but not always.
>
> Are there any other ways?
>