RE: New client-side locking implementation

On Thu, 28 Jul 2005 [email protected] wrote:

> Enumerating known locks through FsRtlGetNextFileLock should yield all the
> relevant locks for an IRP_MN_UNLOCK_ALL_BY_KEY.  The list of locks that you
> see when enumerating will probably not, and is not required to be in sync
> with the list of locks kept in the CM.  However, there should be no locks in
> the CM that are not in the file's FILE_LOCK which match the FileObject,
> Process ID and Key for the request.  All such locks would have originated
> from the IFS side and should already be in the FILE_LOCK.
>
> If you are using a PUNLOCK_ROUTINE callback with FsRtlProcessFileLock, the
> callback receives a PFILE_LOCK_INFO parameter that describes a single lock
> at a time.  The PFILE_LOCK_INFO has enough information to make a call to
> cm_Unlock() as originally suggested (with only one key derived from the
> magic session, Process ID and FileObject).  You shouldn't need to enumerate
> locks manually or depend on the CM knowing about the Key at all.  Confirm?

i originally missed the PFILE_LOCK_INFO parameter to the unlock routine.
while i have not yet had a chance to try this, i agree it looks like it
should work.

> --asanka

eric