The one danger with taking over the byte range locks in a file system
filter driver is that you must be cognizant that they interfere with
oplocks as well. This isn’t insurmountable, but it does underscore the
fact that there are numerous side-effects and special conditions - and
they are neither documented nor required to remain consistent between OS
versions.
I’m not saying that you cannot make this work correctly, I am merely
noting that you may experience untoward side-effects when doing so.
Presumably, this is also an issue that the filter manager folks have
dealt with, given that this is a reasonably common need for file system
filter drivers - and that would be wonderful because it would get
individual filters out of the “let’s take over the byte range locks”
business.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Monday, September 13, 2004 5:20 PM
To: ntfsd redirect
Subject: RE: [ntfsd] open files which are already opened in exclusive
shar ed mode
I worked on a driver that needed this functionality once. The solution
was to implement our own byte range locks and never send upper level
byte range locks to the lower FSD. We kept our own tables and when an
application wanted a range lock, we managed it in our own tables (The
IFS Kit has a set of routines to manipulate byte range locking).
So, if we wanted to allow a service or some other component in our
application to access the files locked ranges, we would detect this via
a process or thread ID (I do not remember the details) any bypass locks;
since we managed the locks and not the file system, we could do that.
Jamey
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ravisankar
Pudipeddi
Sent: Saturday, September 11, 2004 1:34 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] open files which are already opened in exclusive
shar ed mode
In other words memory mapped views will bypass byte range locks. They
may bring on their own set of headaches, but it has been done before.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, September 10, 2004 9:30 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] open files which are already opened in exclusive
shar ed mode
Ken,
No, unfortunately, this technique will not bypass byte range locks. Only
paging I/O operations do that (for read/write).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:</http:>
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Friday, September 10, 2004 10:13 PM
To: ntfsd redirect
Subject: RE: [ntfsd] open files which are already opened in exclusive
shar ed mode
Tony,
Will this approach get around byte range locks?
Thanks,
Ken
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Friday, August 06, 2004 1:53 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] open files which are already opened in exclusive
shared mode
In a filter driver, open the file for some minimal access and then roll
your own IRPs. Access check is done above the level of the filter (not
in the FSD) so this will work.
You could use a filter driver to bypass share access checks as well.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roman Kudinov
Sent: Friday, August 06, 2004 1:35 PM
To: ntfsd redirect
Subject: [ntfsd] open files which are already opened in exclusive shared
mode
Hello all,
What is the best approach to open a file alredy opened in exclusive
shared mode by another process?
I have an idea to emulate sharing in my filter driver, are there any
other easier solutions?
P.S. I’d prefer to open and work with files in user space application
but filter driver is also acceptable
–
Roman Kudinov
mailto:xxxxx@rbcmail.ru
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
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com —
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
__________ NOD32 1.860 (20040903) Information __________
This message was checked by NOD32 antivirus system.
http://www.nod32.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com