This was discussed a little bit recently, but I’m looking for a bit more detail.
Basically, I am implementing implicit lock support in my filter so that I can get out of the way (if I can) if an implicit lock is requested. The metadata example in the Win7 RC WDK describes what an implicit lock operation is for NTFS and FAT. However, I would like to have this work for any file system.
From looking at CDFS, it seems that an implicit lock operation in that case is not sharing read. Whereas for NTFS and FAT it’s not sharing write/delete.
Can I extrapolate by saying that for a read only file system an implicit lock is not sharing read whereas for a read/write filesystem an implicit lock is not sharing write/delete?
I’m sure there is no extrapolation possible here and I am up a creek, but any advice appreciated.
Thanks,
Matt
Why not turn it around the other way?
I use the phrase “implicit locks” but I am slightly unhappy about it since
this isn’t really locking. What is going on is just enforcement of sharing.
If the boot time application is going to do something that would get in the
way of files that are open for write, it will open the volume for no write
share. If the application is concerned that it will mess up open files it
will specify no read share. This is really no different from sharing at a
per file level.
The issue is that it matter more for filters because if they want to be non
intrusive they may need to do explicit things so that the open can work.
But at theoretic level you have exactly the same problem at the per file
level (where delete access on the ::$DATA stream requires delete share for
all open streams) or the per stream level (the one we always think about).
The rule is the same - when you get a create coming down of any sort you
need to close any streams which might get in the way of that create.
Of course, in practice the file and stream case is far less likely than the
volume case - the scope of a volume open with restricted sharing is much
greater and it feels unlikely that filters will try to share streams with
applications.
So getting back to your case you are saying “get out of the way (if I can)”.
My suggestion to you is to stop worrying about whether this is an “implicit
lock” or not, but rather to consider what actions you need - or indeed can -
take when you see a volume open with sharing restricted for read, write or
delete…
You have probably done this already, but if you are looking at these
behaviours I would strongly recommend that you look at the metadata example
for the canonical way of dealing with the LOCK, PNP and MOUNT requests
(which also involve closing any files you may have open)
Rod
Steading System Software.
wrote in message news:xxxxx@ntfsd…
> This was discussed a little bit recently, but I’m looking for a bit more
> detail.
>
> Basically, I am implementing implicit lock support in my filter so that I
> can get out of the way (if I can) if an implicit lock is requested. The
> metadata example in the Win7 RC WDK describes what an implicit lock
> operation is for NTFS and FAT. However, I would like to have this work for
> any file system.
>
> From looking at CDFS, it seems that an implicit lock operation in that
> case is not sharing read. Whereas for NTFS and FAT it’s not sharing
> write/delete.
>
> Can I extrapolate by saying that for a read only file system an implicit
> lock is not sharing read whereas for a read/write filesystem an implicit
> lock is not sharing write/delete?
>
> I’m sure there is no extrapolation possible here and I am up a creek, but
> any advice appreciated.
>
> Thanks,
> Matt
>
>
>