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