That’s true, I checked only FAT and IFS Kit documentation.
Documentation clearly says:
IoGetTopLevelIrp can return NULL, a pointer to the current IRP, or one of
the flags listed in the following table.
Should it be considered as a bug in documentation if Microsoft itself
doesn’t store IRP* in this field?
I used to consider such statements in documentation as a requirement because
other components may rely on it.
Alexei.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
>
> I disagree. Standard file systems store pretty much WHATEVER they want in
> the ETHREAD->TopLevelIrp field. The FSRTL package likes to store constant
> values. FAT as I recall stores an IRP, but other file systems (RDBSS, for
> example) store pointers to thread local storage (generic data structures).
> File systems we write store a generic data structure as well.
>
> There is no mechanism for reliably obtaining the IRP (or operation) from
an
> arbitrary file system.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Alexei Jelvis [mailto:xxxxx@rogers.com]
> Sent: Monday, August 18, 2003 12:35 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: The question about TopLevelIrp can detect
recursive…
>
> Standard file systems are implemented the way that TopLevelIrp contains
> either some predefined values or pointer to the top level IRP.
> You may check the cuurent stack location of this IRP returned by
> IoGetTopLevelIrp.
> By the way, what are you going to achieve? This field is used by file
system
> drivers to get information about locks that are already acquired by the
> current thread and not intended to be used by filter drivers. The primary
> source of recursive calls is a paging IO that is result of normal
read/write
> requests, I would never expect to get an IRP_MJ_CLOSE as a result
> IRP_MJ_CREATE.
>
> Alexei.
>
> “ecore” wrote in message news:xxxxx@ntfsd…
> >
> > TopLevelIrp can detect recursive.But how can I know the
> >
> > original IRP 's MajorFunc?
> > My means is that,I want to know which MajorFunc of original
> >
> > IRP is;
> > for example,IRP_MJ_CREATE will lead to
> >
> > IRP_MJ_CLOSE,recursively.then,when I was at the context of
> >
> > the IRP_MJ_CLOSE,how can I know it is produced by an
> >
> > IRP_MJ_CREATE recursively?
> > thanks for any advice.
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
The documentation is incorrect here about the return values for
IoGetTopIrp. I’ll talk to our doc writer to get it updated
appropriately.
Thanks,
Molly Brown
Microsoft Corporation
This posting is provided “AS IS” with no warranties and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Monday, August 18, 2003 5:50 PM
To: File Systems Developers
Subject: [ntfsd] Re: The question about TopLevelIrp can detect recursi
ve…
That’s true, I checked only FAT and IFS Kit documentation.
Documentation clearly says:
IoGetTopLevelIrp can return NULL, a pointer to the current IRP, or one
of the flags listed in the following table.
Should it be considered as a bug in documentation if Microsoft itself
doesn’t store IRP* in this field?
I used to consider such statements in documentation as a requirement
because other components may rely on it.
Alexei.
“Tony Mason” wrote in message news:xxxxx@ntfsd…
>
> I disagree. Standard file systems store pretty much WHATEVER they
> want in the ETHREAD->TopLevelIrp field. The FSRTL package likes to
> store constant values. FAT as I recall stores an IRP, but other file
> systems (RDBSS, for
> example) store pointers to thread local storage (generic data
structures).
> File systems we write store a generic data structure as well.
>
> There is no mechanism for reliably obtaining the IRP (or operation)
> from
an
> arbitrary file system.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: Alexei Jelvis [mailto:xxxxx@rogers.com]
> Sent: Monday, August 18, 2003 12:35 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: The question about TopLevelIrp can detect
recursive…
>
> Standard file systems are implemented the way that TopLevelIrp
> contains either some predefined values or pointer to the top level
IRP.
> You may check the cuurent stack location of this IRP returned by
> IoGetTopLevelIrp.
> By the way, what are you going to achieve? This field is used by file
system
> drivers to get information about locks that are already acquired by
> the current thread and not intended to be used by filter drivers. The
> primary source of recursive calls is a paging IO that is result of
> normal
read/write
> requests, I would never expect to get an IRP_MJ_CLOSE as a result
> IRP_MJ_CREATE.
>
> Alexei.
>
> “ecore” wrote in message
news:xxxxx@ntfsd…
> >
> > TopLevelIrp can detect recursive.But how can I know the
> >
> > original IRP 's MajorFunc?
> > My means is that,I want to know which MajorFunc of original
> >
> > IRP is;
> > for example,IRP_MJ_CREATE will lead to
> >
> > IRP_MJ_CLOSE,recursively.then,when I was at the context of
> >
> > the IRP_MJ_CLOSE,how can I know it is produced by an
> >
> > IRP_MJ_CREATE recursively?
> > thanks for any advice.
> >
> >
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
> send a blank email to xxxxx@lists.osr.com
>
>
—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com