> Why do I get the write on a file object that is a directory?
No idea, all sorts of odd things happen at the filesystem interface. If you
want to know more I’d start by looking to see who has provoked the write.
Also what the FSD returns.
Why does FltGetStreamContext succeed in write operation when I had not
even set context for it?
Try checking for SL_OPEN_TARGET_DIRECTORY in the create for 2.txt.
(FltObjects->Iopb->OperationFlags). I’m betting that it will be set and the
FO you thought was for “2.txt” is in fact for the parent directory.
First I assume you will find at B is a case of SL_OPEN_TARGET_DIRECTORY;
check the IrpSp->Flags; this is normal for rename operation.
Second I assume you will find at D the non cached writes are paging writes
and refers to the parent directory of the renamed file.
“ganesh pashupathi” wrote in message
news:xxxxx@ntfsd…
Hi,
Following is the scenario that I have on local disk.
1. Go to command prompt.
2. Rename 1.txt to 2.txt.
Following are the calls that come into my skeleton filter:
A. Create call for 1.txt. Say file object address is . I have set a
stream context for this file.
B. Create call for 2.txt. Say file object address is . I have set
stream context for this file.
C. Rename operation comes in for file object . Source file name is
1.txt and destination name is 2.txt.
D. After about 5 to 6 seconds I get a non cached write for a file object
with address . Also if I call the FltIsDirectory fucntion it returns a
1 indicating that the file object is a directory.
In the write call I check to see if context has been set for the file and
only if the context is set I print that the write operation is being done.
Why do I get the write on a file object that is a directory? Why does
FltGetStreamContext succeed in write operation when I had not even set
context for it?
~ganesh
Hello Ganesh
The point is that one does not really set a stream context for a file
object, one really sets a stream context for a stream FileObject->FsContext,
and several file objects share the same stream, so the stream and stream
context is common across multilpe file objects, here FO2 and FO3 sharing the
same stream. One sets a stream handle context for a file object, if one
wants a context unique to the file object.
Best Wishes
Lyndon
“ganesh pashupathi” wrote in message
news:xxxxx@ntfsd…
Hi Rod, Lyndon
Many thanks for your replies.
However, I have a query as to why the stream context was set for 3 file
objects (, and ) and not 2 file objects ( and ).
How is and different?
Thanks in advance,
~ganesh
On Wed, 11 Apr 2007 Lyndon J Clarke wrote :
>First I assume you will find at B is a case of SL_OPEN_TARGET_DIRECTORY;
>check the IrpSp->Flags; this is normal for rename operation.
>
>Second I assume you will find at D the non cached writes are paging writes
>and refers to the parent directory of the renamed file.
>
>“ganesh pashupathi” wrote in message
>news:xxxxx@ntfsd…
>Hi,
>
>Following is the scenario that I have on local disk.
>1. Go to command prompt.
>2. Rename 1.txt to 2.txt.
>
>Following are the calls that come into my skeleton filter:
>A. Create call for 1.txt. Say file object address is . I have set a
>stream context for this file.
>
>B. Create call for 2.txt. Say file object address is . I have set
>stream context for this file.
>
>C. Rename operation comes in for file object . Source file name is
>1.txt and destination name is 2.txt.
>
>D. After about 5 to 6 seconds I get a non cached write for a file object
>with address . Also if I call the FltIsDirectory fucntion it returns a
>1 indicating that the file object is a directory.
>
>In the write call I check to see if context has been set for the file and
>only if the context is set I print that the write operation is being done.
>
>Why do I get the write on a file object that is a directory? Why does
>FltGetStreamContext succeed in write operation when I had not even set
>context for it?
>
>~ganesh
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@rediffmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com