Breaking oplocks

I have a driver that emulates a CD-ROM drive. On the virtual CD-ROM disk,
there is a file, \file.bin, 100 KB in size. Note the file is read-only,
though CDFS wouldn’t allow one to write to the file anyway.

The content (but not the size) of the file may change from beneath CDFS.
Essentially, the file dynamically reflects the state of some external
objects. The changes are infrequent - a few changes per hour. So far so
good, unless the CD-ROM is shared and the file is accessed across the
network.

The problem is with RDR requesting an oplock on the file. The remote clients
only see the local cache and not the changes occurred to the file timestamp
and data since the file was opened. We solved the problem a few years ago by
adding a filter driver on client PCs that does nothing but fails oplock
requests.

Now it’s time to update the driver. We don’t want to leave the filter driver
in place, as it’s not a clean solution and adds unnecessary complexity to
the system.

My question is, how can break all oplocks for a given file or the whole CD
(I guess, we have only Level 2 oplocks) from within the virtual CD-ROM
driver? Once the driver sees the data change, it could break the oplocks and
force the clients to discard the local cache and re-read the file from the
server.

Thanks

> The content (but not the size) of the file may change from beneath CDFS.

Essentially, the file dynamically reflects the state of some external
objects. The changes are infrequent - a few changes per hour. So far so
good, unless the CD-ROM is shared and the file is accessed across the
network.

Emulate the full disc change sequence by properly responding to TEST UNIT READY
and other requests (proper sense info - first “no media in the drive”, next
“unit attention”), and be sure you have changed the CDFS volume serial number
during update of this “virtual CDFS” data.

In this case, for CdRom.sys, you will be the same as the physical disc change.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

This is not acceptable. The clients would have to close all currently open
files. I need to break oplocks for a particular file only.

Thanks

Peter

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
>> The content (but not the size) of the file may change from beneath CDFS.
>> Essentially, the file dynamically reflects the state of some external
>> objects. The changes are infrequent - a few changes per hour. So far so
>> good, unless the CD-ROM is shared and the file is accessed across the
>> network.
>
> Emulate the full disc change sequence by properly responding to TEST UNIT
> READY
> and other requests (proper sense info - first “no media in the drive”,
> next
> “unit attention”), and be sure you have changed the CDFS volume serial
> number
> during update of this “virtual CDFS” data.
>
> In this case, for CdRom.sys, you will be the same as the physical disc
> change.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>

> This is not acceptable.

But this is the only reliable way of updating the virtual disk from under the
FSD.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

If you want to do this from above the FSD, you can open the file and
take out a byte range lock. That should trigger an oplock break
(although I have not confirmed this would happen on CDFS, it will
certainly happen on FAT or NTFS because byte range locks are
incompatible with level 1, 2 or batch oplocks, and the second open would
be incompatible with a filter oplock.)

A quick check indicates the byte range lock IS sent to the oplock
package (see lockctrl.c):

//
// We check whether we can proceed based on the state of the file
oplocks.
// This call might post the irp for us.
//

Status = FsRtlCheckOplock( &Fcb->Oplock,
Irp,
IrpContext,
CdOplockComplete,
NULL );

Thus, I would expect the same behavior (note this is also in the fast
I/O path, so again, it sure looks like it works the same on CDFS as it
would on FAT.)

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, March 20, 2006 6:20 PM
To: ntfsd redirect
Subject: Re: Re:[ntfsd] Breaking oplocks

This is not acceptable.

But this is the only reliable way of updating the virtual disk from
under the
FSD.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com