Hi!
I want to record all the files that have been opened or created. But I can not tell apart files from directories by interpreting IRP_MJ_CREATE. Or should I do this by interpreting some other IRPs? Can someone give me some suggestion?
Thanks in advance!
If your writting a mini-filter(which you should be), take a look at
FltIsDirectory.
m.
headium2006@163.com wrote:
Hi!
I want to record all the files that have been opened or created. But I can not tell apart files from directories by interpreting IRP_MJ_CREATE. Or should I do this by interpreting some other IRPs? Can someone give me some suggestion?
Thanks in advance!
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com
You can detect directories in the Create dispatch functions by investigating
the following:
Check the flags FILE_DIRECTORY_FILE (for directories) and
FILE_NON_DIRECTORY_FILE(for files) in the valid option flags in
pCurrentIrpStack->Parameters.Create.Options.
Check the name in FileObject.Filename if its a directory (may only apply for
root directory).
I suggest you search this group on the osronline web page - the subject has
come up quite a number of times 
“Adam Darmanin” wrote in message news:xxxxx@ntfsd…
> You can detect directories in the Create dispatch functions by
> investigating the following:
>
> Check the flags FILE_DIRECTORY_FILE (for directories) and
> FILE_NON_DIRECTORY_FILE(for files) in the valid option flags in
> pCurrentIrpStack->Parameters.Create.Options.
>
> Check the name in FileObject.Filename if its a directory (may only apply
> for root directory).
>
>
>
Thanks!
I’ll try to find some useful info on this web!
Hi,
You can use:
FltObjects->FileObject->WriteAccess
FltObjects->FileObject->ReadAccess
FltObjects->FileObject->DeleteAccess
FLT_POSTOP_CALLBACK_STATUS XXXXPostCreate ()
Greetings
Samuel Raya
Jefe de Dpto. Investigación y Desarrollo
S2F ENTERTAINMENT
(511) 95664321
Lima - PERÚ
Hi, Samuel!
Thanks for your reply! But I don’t know what “FltObjects” is? Does it only exist in MiniFilter Driver?
FltObjects is the second parameter of IRP_MJ_CREATE post event callback
in a mini-filter.
typedef FLT_POSTOP_CALLBACK_STATUS
(*PFLT_POST_OPERATION_CALLBACK) (
IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags
);
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
headium2006@163.com
Sent: 28 September 2006 03:04
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
*** WARNING ***
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
Hi, Samuel!
Thanks for your reply! But I don’t know what “FltObjects” is? Does it
only exist in MiniFilter Driver?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@baesystems.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
Thanks Jonathan!
But I am not writing a mini-filter driver!
So far as I know the Options field in IRP_MJ_CREATE IRP packet can be used to judge whether a
dir or file is being opened. But there is something interesting occured in my test.
If a dir is named like “1236.mp3” then the Options field in IRP_MJ_CREATE is set as FILE_NON_DIRECTORY_FILE. But it does be a dir! Why?
Can someone tell me the reasons? Thanks!!!
If you are not writing a Mini-Filter, so cant use FltIsDirectory, then
you will have to query the underlying filesystem to determine if the
create was a directory or file.
You will have to roll your own IRP_MJ_QUERY_INFORMATION IRP and send it
to the lower filesystem to get the attributes for the opened file.
Ben
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
headium2006@163.com
Sent: 28 September 2006 13:47
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
Thanks Jonathan!
But I am not writing a mini-filter driver!
So far as I know the Options field in IRP_MJ_CREATE IRP packet can be
used to judge whether a
dir or file is being opened. But there is something interesting occured
in my test.
If a dir is named like “1236.mp3” then the Options field in
IRP_MJ_CREATE is set as FILE_NON_DIRECTORY_FILE. But it does be a dir!
Why?
Can someone tell me the reasons? Thanks!!!
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
If I understand your question right, you are asking “why would an
application pass down a set of parameters that do not make sense.”
And the answer is: “because they are allowed to do so.”
I think you misunderstand FILE_NON_DIRECTORY_FILE (and yes, this is in
the archives. Try a search from Google saying “FILE_NON_DIRECTORY_FILE
site:osronline.com” and you’ll find discussions of this very topic.)
The purpose of FILE_DIRECTORY_FILE is so that an application can say
“open this up but ONLY if it is a directory.” And similarly
FILE_NON_DIRECTORY_FILE says “open this up UNLESS it is a directory.”
But an application can say “open this up” and specify neither. (And to
confuse you, it can say both…)
In your filter, you want to know what the object is - this is akin to
asking “what is in the box” without benefit of having opened the box.
You won’t know what is in that box (the file/directory) until you open
and look at it (perhaps it will be a dead cat? Or a live cat?)
So, either wait until someone ELSE has opened the box and then peek
inside, or open it yourself…
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 headium2006@163.com
Sent: Thursday, September 28, 2006 5:47 AM
To: ntfsd redirect
Subject: RE:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
Thanks Jonathan!
But I am not writing a mini-filter driver!
So far as I know the Options field in IRP_MJ_CREATE IRP packet can be
used to judge whether a
dir or file is being opened. But there is something interesting occured
in my test.
If a dir is named like “1236.mp3” then the Options field in
IRP_MJ_CREATE is set as FILE_NON_DIRECTORY_FILE. But it does be a dir!
Why?
Can someone tell me the reasons? Thanks!!!
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
Hmm, nice idea, quantum file systems, hmm …
“Tony Mason” wrote in message news:xxxxx@ntfsd…
If I understand your question right, you are asking “why would an
application pass down a set of parameters that do not make sense.”
And the answer is: “because they are allowed to do so.”
I think you misunderstand FILE_NON_DIRECTORY_FILE (and yes, this is in
the archives. Try a search from Google saying “FILE_NON_DIRECTORY_FILE
site:osronline.com” and you’ll find discussions of this very topic.)
The purpose of FILE_DIRECTORY_FILE is so that an application can say
“open this up but ONLY if it is a directory.” And similarly
FILE_NON_DIRECTORY_FILE says “open this up UNLESS it is a directory.”
But an application can say “open this up” and specify neither. (And to
confuse you, it can say both…)
In your filter, you want to know what the object is - this is akin to
asking “what is in the box” without benefit of having opened the box.
You won’t know what is in that box (the file/directory) until you open
and look at it (perhaps it will be a dead cat? Or a live cat?)
So, either wait until someone ELSE has opened the box and then peek
inside, or open it yourself…
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 headium2006@163.com
Sent: Thursday, September 28, 2006 5:47 AM
To: ntfsd redirect
Subject: RE:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
Thanks Jonathan!
But I am not writing a mini-filter driver!
So far as I know the Options field in IRP_MJ_CREATE IRP packet can be
used to judge whether a
dir or file is being opened. But there is something interesting occured
in my test.
If a dir is named like “1236.mp3” then the Options field in
IRP_MJ_CREATE is set as FILE_NON_DIRECTORY_FILE. But it does be a dir!
Why?
Can someone tell me the reasons? Thanks!!!
—
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
Actually, this is something I periodically run across (the idea of
uncertainty, not quantum mechanics in file systems per-se…)
I recently had a developer asking about a bug his test team had logged
against him. The test program had two threads that issues asynchronous
overlapping write operations and his filter’s responsibility was to
create an identical copy of the file (“data backup”). The test team was
unhappy because he wasn’t giving them reliable results in this
particular case.
I in fact argued that what you had were (at least) two probability
states for the file, both perfectly valid based upon the original
operation set. If we increased the number of simultaneous writer
threads and vary their overlap region we can see that rather quickly the
number of valid possible states increases dramatically.
It is an interesting demonstration of causality - I see two requests
race to the FSD, and I see them when they come back, but I can’t tell
from that the order of execution.
Programmers often want to view the world as deterministic, but I would
argue that this view is overly simplistic (and not realistic.) In this
specific case the programmer can FORCE determinism (and thus close the
bug) by turning the asynchronous operations into synchronous operations,
but that seems like quite a lot of mechanism for fixing a test that is
fundamentally broken in its expectations.
There - something NEW for the archives “On The Quantum Mechanical-like
Nature of Asynchronous I/O in a Windows File System.” My day is
complete and it is still morning!
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 Lyndon J. Clarke
Sent: Thursday, September 28, 2006 7:17 AM
To: ntfsd redirect
Subject: Re:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
Hmm, nice idea, quantum file systems, hmm …
[omitted text]
I hope we can capture you in this thread a little longer. On the semantics
of the file systems in windows …
In the simplest case where the two writes are different data but the exact
same byte range in the file^H^H^H^Hstream. Imagine on of the writes has all
bytes set to ‘A’ and the other has all bytes set to ‘B’.
Two valid states are that the byte range of the file at the end contains all
‘A’ or all ‘B’.
Are there valid states where some of the byte range in the file contains ‘A’
and some of the byte range in the file contains ‘B’?
Are there valid states where some of the byte range in the file contains
neither ‘A’ nor ‘B’?
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Actually, this is something I periodically run across (the idea of
uncertainty, not quantum mechanics in file systems per-se…)
I recently had a developer asking about a bug his test team had logged
against him. The test program had two threads that issues asynchronous
overlapping write operations and his filter’s responsibility was to
create an identical copy of the file (“data backup”). The test team was
unhappy because he wasn’t giving them reliable results in this
particular case.
I in fact argued that what you had were (at least) two probability
states for the file, both perfectly valid based upon the original
operation set. If we increased the number of simultaneous writer
threads and vary their overlap region we can see that rather quickly the
number of valid possible states increases dramatically.
It is an interesting demonstration of causality - I see two requests
race to the FSD, and I see them when they come back, but I can’t tell
from that the order of execution.
Programmers often want to view the world as deterministic, but I would
argue that this view is overly simplistic (and not realistic.) In this
specific case the programmer can FORCE determinism (and thus close the
bug) by turning the asynchronous operations into synchronous operations,
but that seems like quite a lot of mechanism for fixing a test that is
fundamentally broken in its expectations.
There - something NEW for the archives “On The Quantum Mechanical-like
Nature of Asynchronous I/O in a Windows File System.” My day is
complete and it is still morning!
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 Lyndon J. Clarke
Sent: Thursday, September 28, 2006 7:17 AM
To: ntfsd redirect
Subject: Re:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
Hmm, nice idea, quantum file systems, hmm …
[omitted text]
Let’s create a hypothetical test program:
This is simple, but it demonstrates the problem - each THREAD here is
synchronous, but the underlying OS presents each of these I/O operations
as a discrete asynchronous I/O operation.
Now, the question becomes: “If I pull the plug on the machine and then
examine the state of the file, is there a single valid state?” The
answer to this should be fairly clear to almost everyone: “no”.
The total set of possible states is going to depend upon details of the
file system implementation. We could, for example, have a file system
that serializes all I/O operations (but don’t run a database on such an
FSD because performance will be bad.) Perhaps the FSD breaks up these
I/O operations into multiple disjoint pieces (look in the WDK for
“Associated Irps” and look at the corresponding code in FAT (deviosup.c
as I recall) and see how it can take one operation and break it up into
multiple disjoint operations.
So, my quick conclusion from this thought experiment is that in fact
it’s probably possible that ALL combinations of states at the atomic
level of write could occur - and would be valid outcomes. Determining
specific of the probability cloud here would likely involve a thorough
understanding of the actual hardware.
Of course we have transactional systems available to us to help protect
against such non-deterministic behavior.
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 Lyndon J. Clarke
Sent: Thursday, September 28, 2006 8:24 AM
To: ntfsd redirect
Subject: Re:[ntfsd] How to judge a file is been read by IRP_MJ_CREATE?
I hope we can capture you in this thread a little longer. On the
semantics
of the file systems in windows …
In the simplest case where the two writes are different data but the
exact
same byte range in the file^H^H^H^Hstream. Imagine on of the writes has
all
bytes set to ‘A’ and the other has all bytes set to ‘B’.
Two valid states are that the byte range of the file at the end contains
all
‘A’ or all ‘B’.
Are there valid states where some of the byte range in the file contains
‘A’
and some of the byte range in the file contains ‘B’?
Are there valid states where some of the byte range in the file contains
neither ‘A’ nor ‘B’?
[omitted quoted text]