What is the best way to access the ShareAccess field of fcb.h from
FltObjects->FileObject->FsContext?
I have looked at many data structures like FSRTL_ADVANCED_FCB_HEADE,
FSRTL_COMMON_FCB_HEADER, fcb.h and wonder if there is a MACRO
will get the ShareAccess field of fcb.h from FsContext?
>What is the best way to access the ShareAccess field of fcb.h from
FltObjects->FileObject->FsContext?
The file system owns the FsContext field, you can’t go poking in it because
the structure of it is defined by the FSD. Even if you could figure out the
offset of the field that you want you’re not serializing yourself with the
FSD’s access of it.
What problem are you trying to solve?
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
Scott,
Many different file objects that access the same identical file get
created and deleted as Create and Cleanup callback functions get
invoked. Those file objects have different ShareAccess to the same
file. Knowing the last ShareAccess on the file, which I think may be
recorded in the ShareAccess field of fcb structure , can help the
next FltCreateFile() call to avoid the STATUS_SHARING_VIOLATION
error. This is one of many problems can be solved with information
from fcb structure. A minifilter can have its own data structure to keep
track of ShareAccess to a file. But if the information can be found on
the fcb, why duplicate the effort and waste the resources.
The serialization of accessing the file can be handled
by the minifilter.
Perhaps, people from Microsoft on this email list can shed some
lights on this.
John W.
>What is the best way to access the ShareAccess field of fcb.h from
>FltObjects->FileObject->FsContext?The file system owns the FsContext field, you can’t go poking in it
because
the structure of it is defined by the FSD. Even if you could figure out
the
offset of the field that you want you’re not serializing yourself with the
FSD’s access of it.What problem are you trying to solve?
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
You could set IO_IGNORE_SHARE_ACCESS_CHECK in the flags when calling
FltCreateFile().
Thanks,
Alex.
The IO_IGNORE_SHARE_ACCESS_CHECK flag does not
work for LanManRedirector.
John W.
You could set IO_IGNORE_SHARE_ACCESS_CHECK in the flags when calling
FltCreateFile().Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>Knowing the last ShareAccess on the file, which I think may be
recorded in the ShareAccess field of fcb structure , can help the
next FltCreateFile() call to avoid the STATUS_SHARING_VIOLATION
error
How so? What do you do in the case where you determine that you’ll get a
sharing violation? As Alex mentioned, setting IO_IGNORE_SHARE_ACCESS_CHECK
solves this problem for you.
The serialization of accessing the file can be handled
by the minifilter.
How do you guarantee that no one beneath your filter opens the file and
changes the share access?
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
But this makes sense. You are a client of the file system. When you’re
talking to a local file system you can tell it to ignore the checks it would
normally do by convincing it that you are trusted and you know what you are
doing (by being a kernel mode caller and/or using
IO_IGNORE_SHARE_ACCESS_CHECK). This is an override built in the
communication protocol (which is the collection of IRPs and such that a
local file system responds to).
When talking to a remote file system, the communication protocol is
different and unless it implements such an override, there is nothing you
can do.
Moreover, I doubt that even if you looked at the ShareAccess in the FCB
structure for the local FILE_OBJECT (that the one that the network file
system has returned to the IO manager) your approach would work, because I
don’t think there are any guarantees that the local ShareAccess is kept in
sync with the one on the server. It don’t know how that could even possibly
work since knowing what the ShareAccess is *now* doesn’t mean that it will
be the same when your request reaches the server because the server will
process requests you don’t see. This would work for a local file system
where you see all the operations, but not on the server.
IMO you keep thinking about the problem in terms of local file systems and
working on remote file system requires a perspective change.
Thanks,
Alex.
To add to my previous post, this statement touches on the crux of the issue
“The serialization of accessing the file can be handled by the minifilter.”
How can a minifilter running on a client serialize access to a file on a
server (unless the protocol provides such a capability) ?
Thanks,
Alex.
Scott,
The ShareAccess Flag is passed down from the application.
For example, the Word opens and closes the temp file ~WRD***.tmp
many times during a write. Each open request has different ShareAccess
flag on the same ~WRD***.tmp file.
To change the ShareAccess flag in the kernel space
will cause problem for the application.
STATUS_SHARING_VIOLATION is one of many problems that can
be solved with information from fcb structure, I think.
Please check out this thread,
http://www.osronline.com/showThread.cfm?link=181286
John W.
>The serialization of accessing the file can be handled
>by the minifilter.How do you guarantee that no one beneath your filter opens the file and
changes the share access?-scott
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Alex,
Thanks for your information and questions.
Sorry for getting sidetracked to this serialization issue. That is not
what I asked for.
All I want to know is how to get to fcb structure of a file system from
the FltObjects->FileObject->FsContext field.
We are working on the file system, either minifilter or legacy filter, and
should be allowed to access the File Control Block.
John W.
To add to my previous post, this statement touches on the crux of the
issue
“The serialization of accessing the file can be handled by the
minifilter.”How can a minifilter running on a client serialize access to a file on a
server (unless the protocol provides such a capability) ?Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“xxxxx@TwinPeakSoft.com” wrote in message
news:xxxxx@ntfsd:
> Alex,
>
> Thanks for your information and questions.
> Sorry for getting sidetracked to this serialization issue. That is not
> what I asked for.
> All I want to know is how to get to fcb structure of a file system from
> the FltObjects->FileObject->FsContext field.
> We are working on the file system, either minifilter or legacy filter, and
> should be allowed to access the File Control Block.
>
> John W.
No you are working on a file system filter, only the file system is
allowed access to the FsContext field. As people have been telling you
don’t go there. On your link to a previous thread, did you notice that
the OP did not get an answer to how to solve his problem?
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
>To change the ShareAccess flag in the kernel space will cause problem for
the application.
That’s a specific example of a general problem though. Just because it might
or might not be a good idea in specific situations doesn’t mean that it
can’t or shouldn’t be done.
You still haven’t said exactly what you’re trying to do, there might be a
solution that doesn’t require doing something unsupported. There ARE other
ways of getting around sharing violations, though it’s not clear that is
even what you’re trying to do.
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
Well, as Scott has already mentioned, there is no generic FCB structure, it
is specific to each file system. Moreover, even when running on one file
system a filter below you can complete an IRP_MJ_CREATE and take ownership
of that FILE_OBJECT and then that one FILE_OBJECT will have a different FCB
structure.
A filter should not make assumptions about the FCB structure (outside of the
documented parts, see the FSRTL_ADVANCED_FCB_HEADER structure and related
documentation).
You should probably explain in more detail what it is you are trying to
accomplish. See the famous NT Insider article on asking questions on the OSR
lists (http://www.osronline.com/downloads/pp_asking.pdf).
Thanks,
Alex.
Alex,
We are implementing the Mirror File System(patented) on Windows
platform for real time file system mirroring.
Every file update and operation sent from applications to kernel
space will be mirrored between NTFS and CIFS. As mentioned earlier,
some applications like Word and Power Point open the same file
many time during process. But not all opens have same ShareAccess
mode. To NTFS, this is not a problem since we can set
IO_IGNORE_SHARE_ACCESS_CHECK. But CIFS does not honor
that flag. Since there are only 8 different ShareAccess modes, 0-7.
One approach we use is to loop through each mode when get error
code STATUS_SHARING_VIOLATION return code for an open call.
It’s not an efficient way to do, bit it seems to work. Another way is to
keep track of the ShareAccess mode used before for the new open call.
The third approach is the question I posted on this thread.
Thanks for your help.
John W.
You should probably explain in more detail what it is you are trying to
accomplish. See the famous NT Insider article on asking questions on the
OSR
lists (http://www.osronline.com/downloads/pp_asking.pdf).Thanks,
Alex.
I’m not sure I understand exactly what goes on. So when you see an
IRP_MJ_CREATE on NTFS do you send a similar IRP_MJ_CREATE to CIFS ?
Is it possible that other clients are accessing the same file on CIFS or can
you guarantee that you are the only one accessing it ?
Thanks,
Alex.
You can lock the file and guarantee that you are the only one accessing it.
John W.
I’m not sure I understand exactly what goes on. So when you see an
IRP_MJ_CREATE on NTFS do you send a similar IRP_MJ_CREATE to CIFS ?Is it possible that other clients are accessing the same file on CIFS or
can
you guarantee that you are the only one accessing it ?Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
John W.
Twin Peaks Software
Innovation for business continuity
E-mail: xxxxx@TwinPeakSoft.com
Tel: (510) 438-0536
But in order to lock it you must have a handle to it. Which means you
already managed to get a successful IRP_MJ_CREATE through… But I thought
we were talking about the case where you can’t open the file over CIFS at
all because of a sharing violation.
Thanks,
Alex.
Alex,
We did not have problem for opening the file initially, only during
the process when file handles get closed and open again.
John W.
But in order to lock it you must have a handle to it. Which means you
already managed to get a successful IRP_MJ_CREATE through… But I thought
we were talking about the case where you can’t open the file over CIFS at
all because of a sharing violation.Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
So why not use the initial handle for the remove file for performing the
operations you need to perform anyway ?
If you’re simply trying to mirror all IO from an NTFS volume to a CIFS
volume then you’ll run into other issues because the two quite different in
some cases. Besides, NTFS has different semantics from CIFS so some
operations will simply make no sense on CIFS (alternate data streams,
hardlinks and many other things that are NTFS specific).
Anyway, as a workaround you could send all requests for the CIFS volume with
full sharing (your ZwCreateFile call would always have
SHARE_READ|SHARE_WRITE|SHARE_DELETE) and then use the local NTFS volume for
sharing validation. Basically, you let the IRP_MJ_CREATE reach NTFS and in
the postCreate if you get a STATUS_SHARING_VIOLATION then you know that the
create needs to fail anyway (even though your ZwCreateFile call didn’t fail)
and if the IRP_MJ_CREATE is successful then you know that the share checks
performed by NTFS were successful. Another way to put this is that you
disable any sharing checks on the remote volume (since all your creates for
the remote volume are sharing everything) and you use the local volume as a
reference.
Thanks,
Alex.
Alex,
Thanks for your good suggestions.
We will try them.
Thanks,
John W.