Hello,
in VPB is reference count so:
-
who increments this count and when?
-
I suppose, that who increments, the same decrements?
-
I saw in CDFS that it sometimes change VPB pointers in
structures and sometimes dealocate VPB - so who is responsible
for deallocating the structure (is it posible to delete VPB even
if I havent allocated it before?)
-
By what I can determine, if I have allocated the structure or
if this was done by someone else (I suppose reference count??)
-
Is it possible for VPB to remain in memory when its reference
count is zero?
These problems are due to my actual work on removable media FS
Filter. I’m not sure, when I should delete my FilterDevice so as
it wasn’t so early.
Thanks Ondra.
Centrum pro milovn?ky pen?z http://finance.centrum.cz
>1) who increments this count and when?
Any file object created on the mounted volume holds a reference to
VPB.
Addrefed just before sending CREATE, derefed in CLOSE path - IIRC in
IopDeleteFile.
structures and sometimes dealocate VPB - so who is responsible
for deallocating the structure (is it posible to delete VPB even
if I havent allocated it before?)
It is a rather complex thing. The initial VPB for the disk device
object is created by the IO manager in IoCreateDevice. Nevertheless,
when the FSD discovers media change, it is responsible in allocating a
new blank VPB and attaching it to the disk DO. The old VPB does now
belong to FSD, not to IO manager, and is linked to one of the
not-mounted FSD’s VCBs.
When old media will be back in the drive, the FSD will re-attach this
“not-mounted” VPB to the disk DO.
- Is it possible for VPB to remain in memory when its reference
count is zero?
What is the need in this?
These problems are due to my actual work on removable media FS
Filter.
Filter all mount requests as usually - anyway mounting the drive after
media change will be done by usual mount path.
Nevertheless, remount will not.
To track what of several FSD’s volume DOs is really connected to the
disk DO, you can grab the VPB spinlock and check whether it is really
double-linked to the disk DO. If not so - then this is “not-mounted”
volume due to media change, the FSD will either remount it when that
media will be back in drive, or destroy it when all files on it are
closed.
The lifetime of your filter’s DOs can be tracked by using
FastIoDetachDevice, which must be complex enough to destroy the whole
device extension.
Max