In my filter driver I am seeing IRP_MJ_CREATE for file objects but no
IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
The filter driver is a simple driver that keeps track of file objects
created and destroyed and nothing else. After a while since the driver did
not
see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
invalid or worse yet, entries that are valid but point to different target.
Regds
You may not see close IRP for a (potentially very long) while - it’s
normal behavior when files were cached/memory mapped. But the fact that
you don’t see cleanups may be evidence that a) file handles are never
closed (very unlikely) or b) you have a bug in your hash table lookup
routine (most likely).
Regards,
Vladimir
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 7:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
In my filter driver I am seeing IRP_MJ_CREATE for file objects but
no
IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
The filter driver is a simple driver that keeps track of file
objects
created and destroyed and nothing else. After a while since the driver
did
not
see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
invalid or worse yet, entries that are valid but point to different
target.
Regds
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
the hash table has been regressed over the full range of data. no bugs
in the table lookup code.
also the file handles are closed as is visible from the fact that the
fileobject in the hash table when checked by “!ojbect” debugger command
points to a different directory object.
is it possible that the filter driver could not see IRP_MJ_CLOSE if it
is loaded dynamically ?
–
Regds
“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
You may not see close IRP for a (potentially very long) while - it’s
normal behavior when files were cached/memory mapped. But the fact that
you don’t see cleanups may be evidence that a) file handles are never
closed (very unlikely) or b) you have a bug in your hash table lookup
routine (most likely).
Regards,
Vladimir
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 7:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
In my filter driver I am seeing IRP_MJ_CREATE for file objects but
no
IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
The filter driver is a simple driver that keeps track of file
objects
created and destroyed and nothing else. After a while since the driver
did
not
see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
invalid or worse yet, entries that are valid but point to different
target.
-----
Regds
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
There must be some hole in the way you match FileObjects with
corresponded metadata that you store for them in the hash. For each FO
for which you saw Create you’re going to see Cleanup when file’s handle
is closed. Close requests is another story (they may never come at all).
There also can be cases when you see Cleanups and Closes for FileObject
for which you didn’t see Creates (like, for example, stream FOs). So,
just carefully debug your code on a single file (command line “type
foo.cpp” command is my favorite) and see how do you track that
FileObject…
Regards,
Vladimir
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 1:53 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
the hash table has been regressed over the full range of data. no
bugs
in the table lookup code.
also the file handles are closed as is visible from the fact that
the
fileobject in the hash table when checked by “!ojbect” debugger command
points to a different directory object.
is it possible that the filter driver could not see IRP_MJ_CLOSE if
it
is loaded dynamically ?
–
Regds
“Vladimir Chtchetkine” wrote in
message
news:xxxxx@ntfsd…
You may not see close IRP for a (potentially very long) while - it’s
normal behavior when files were cached/memory mapped. But the fact that
you don’t see cleanups may be evidence that a) file handles are never
closed (very unlikely) or b) you have a bug in your hash table lookup
routine (most likely).
Regards,
Vladimir
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 7:58 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
In my filter driver I am seeing IRP_MJ_CREATE for file objects but
no
IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
The filter driver is a simple driver that keeps track of file
objects
created and destroyed and nothing else. After a while since the driver
did
not
see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
invalid or worse yet, entries that are valid but point to different
target.
-----
Regds
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Also I would like to add that I am hooking only the lanman redirector
–
Regds
“Navin” wrote in message news:xxxxx@ntfsd…
> the hash table has been regressed over the full range of data. no bugs
> in the table lookup code.
>
> also the file handles are closed as is visible from the fact that the
> fileobject in the hash table when checked by “!ojbect” debugger command
> points to a different directory object.
>
> is it possible that the filter driver could not see IRP_MJ_CLOSE if it
> is loaded dynamically ?
>
> –
> Regds
>
>
>
> “Vladimir Chtchetkine” wrote in message
> news:xxxxx@ntfsd…
> You may not see close IRP for a (potentially very long) while - it’s
> normal behavior when files were cached/memory mapped. But the fact that
> you don’t see cleanups may be evidence that a) file handles are never
> closed (very unlikely) or b) you have a bug in your hash table lookup
> routine (most likely).
>
> Regards,
>
> Vladimir
>
> -----Original Message-----
> From: Navin [mailto:xxxxx@yahoo.com]
> Sent: Friday, February 27, 2004 7:58 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but
> no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
>
> The filter driver is a simple driver that keeps track of file
> objects
> created and destroyed and nothing else. After a while since the driver
> did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
> invalid or worse yet, entries that are valid but point to different
> target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
What are you using for indexing into the table?
FileObject, FileObject->FsContext, file path, something else…?
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 3:07 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
Also I would like to add that I am hooking only the lanman redirector
–
Regds
“Navin” wrote in message news:xxxxx@ntfsd…
> the hash table has been regressed over the full range of data. no
bugs
> in the table lookup code.
>
> also the file handles are closed as is visible from the fact that
the
> fileobject in the hash table when checked by “!ojbect” debugger
command
> points to a different directory object.
>
> is it possible that the filter driver could not see IRP_MJ_CLOSE
if it
> is loaded dynamically ?
>
> –
> Regds
>
>
>
> “Vladimir Chtchetkine” wrote in
message
> news:xxxxx@ntfsd…
> You may not see close IRP for a (potentially very long) while - it’s
> normal behavior when files were cached/memory mapped. But the fact
that
> you don’t see cleanups may be evidence that a) file handles are never
> closed (very unlikely) or b) you have a bug in your hash table lookup
> routine (most likely).
>
> Regards,
>
> Vladimir
>
> -----Original Message-----
> From: Navin [mailto:xxxxx@yahoo.com]
> Sent: Friday, February 27, 2004 7:58 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but
> no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible
?
>
> The filter driver is a simple driver that keeps track of file
> objects
> created and destroyed and nothing else. After a while since the driver
> did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that
are
> invalid or worse yet, entries that are valid but point to different
> target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I am using FileObject for indexing into the table. I found the problem.
I am adding the FileObject to the hash table without checking whether the
call succeeded or not. I changed the code to add the object to hash table
only if the call to lower lever driver succeeds and everything is working
fine now.
Thanks for your help.
–
Regds
“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
What are you using for indexing into the table?
FileObject, FileObject->FsContext, file path, something else…?
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 3:07 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
Also I would like to add that I am hooking only the lanman redirector
–
Regds
“Navin” wrote in message news:xxxxx@ntfsd…
> the hash table has been regressed over the full range of data. no
bugs
> in the table lookup code.
>
> also the file handles are closed as is visible from the fact that
the
> fileobject in the hash table when checked by “!ojbect” debugger
command
> points to a different directory object.
>
> is it possible that the filter driver could not see IRP_MJ_CLOSE
if it
> is loaded dynamically ?
>
> –
> Regds
>
>
>
> “Vladimir Chtchetkine” wrote in
message
> news:xxxxx@ntfsd…
> You may not see close IRP for a (potentially very long) while - it’s
> normal behavior when files were cached/memory mapped. But the fact
that
> you don’t see cleanups may be evidence that a) file handles are never
> closed (very unlikely) or b) you have a bug in your hash table lookup
> routine (most likely).
>
> Regards,
>
> Vladimir
>
> -----Original Message-----
> From: Navin [mailto:xxxxx@yahoo.com]
> Sent: Friday, February 27, 2004 7:58 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but
> no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible
?
>
> The filter driver is a simple driver that keeps track of file
> objects
> created and destroyed and nothing else. After a while since the driver
> did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that
are
> invalid or worse yet, entries that are valid but point to different
> target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Just in case (it was one of my mistakes) 
Don’t use NT_SUCCESS macro
only to verify success of create. Because, for example, STATUS_REPARSE
and STATUS_REPARSE_OBJECT will pass this check, but file has not been
actually opened…
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 4:22 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
I am using FileObject for indexing into the table. I found the
problem.
I am adding the FileObject to the hash table without checking whether
the
call succeeded or not. I changed the code to add the object to hash
table
only if the call to lower lever driver succeeds and everything is
working
fine now.
Thanks for your help.
–
Regds
“Vladimir Chtchetkine” wrote in
message
news:xxxxx@ntfsd…
What are you using for indexing into the table?
FileObject, FileObject->FsContext, file path, something else…?
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 3:07 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
Also I would like to add that I am hooking only the lanman redirector
–
Regds
“Navin” wrote in message news:xxxxx@ntfsd…
> the hash table has been regressed over the full range of data. no
bugs
> in the table lookup code.
>
> also the file handles are closed as is visible from the fact that
the
> fileobject in the hash table when checked by “!ojbect” debugger
command
> points to a different directory object.
>
> is it possible that the filter driver could not see IRP_MJ_CLOSE
if it
> is loaded dynamically ?
>
> –
> Regds
>
>
>
> “Vladimir Chtchetkine” wrote in
message
> news:xxxxx@ntfsd…
> You may not see close IRP for a (potentially very long) while - it’s
> normal behavior when files were cached/memory mapped. But the fact
that
> you don’t see cleanups may be evidence that a) file handles are never
> closed (very unlikely) or b) you have a bug in your hash table lookup
> routine (most likely).
>
> Regards,
>
> Vladimir
>
> -----Original Message-----
> From: Navin [mailto:xxxxx@yahoo.com]
> Sent: Friday, February 27, 2004 7:58 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but
> no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible
?
>
> The filter driver is a simple driver that keeps track of file
> objects
> created and destroyed and nothing else. After a while since the driver
> did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that
are
> invalid or worse yet, entries that are valid but point to different
> target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Oh boy, do I so know where you come from., with this hint … happy times
“Vladimir Chtchetkine” wrote in message
news:xxxxx@ntfsd…
Just in case (it was one of my mistakes) Don’t use NT_SUCCESS macro
only to verify success of create. Because, for example, STATUS_REPARSE
and STATUS_REPARSE_OBJECT will pass this check, but file has not been
actually opened…
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 4:22 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
I am using FileObject for indexing into the table. I found the
problem.
I am adding the FileObject to the hash table without checking whether
the
call succeeded or not. I changed the code to add the object to hash
table
only if the call to lower lever driver succeeds and everything is
working
fine now.
Thanks for your help.
–
Regds
“Vladimir Chtchetkine” wrote in
message
news:xxxxx@ntfsd…
What are you using for indexing into the table?
FileObject, FileObject->FsContext, file path, something else…?
-----Original Message-----
From: Navin [mailto:xxxxx@yahoo.com]
Sent: Friday, February 27, 2004 3:07 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
Also I would like to add that I am hooking only the lanman redirector
–
Regds
“Navin” wrote in message news:xxxxx@ntfsd…
> the hash table has been regressed over the full range of data. no
bugs
> in the table lookup code.
>
> also the file handles are closed as is visible from the fact that
the
> fileobject in the hash table when checked by “!ojbect” debugger
command
> points to a different directory object.
>
> is it possible that the filter driver could not see IRP_MJ_CLOSE
if it
> is loaded dynamically ?
>
> –
> Regds
>
>
>
> “Vladimir Chtchetkine” wrote in
message
> news:xxxxx@ntfsd…
> You may not see close IRP for a (potentially very long) while - it’s
> normal behavior when files were cached/memory mapped. But the fact
that
> you don’t see cleanups may be evidence that a) file handles are never
> closed (very unlikely) or b) you have a bug in your hash table lookup
> routine (most likely).
>
> Regards,
>
> Vladimir
>
> -----Original Message-----
> From: Navin [mailto:xxxxx@yahoo.com]
> Sent: Friday, February 27, 2004 7:58 AM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but
> no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible
?
>
> The filter driver is a simple driver that keeps track of file
> objects
> created and destroyed and nothing else. After a while since the driver
> did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that
are
> invalid or worse yet, entries that are valid but point to different
> target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@borland.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as:
xxxxx@borland.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Pagefile or hibernation file. Opened and never ever closed.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Navin”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Friday, February 27, 2004 6:58 PM
Subject: [ntfsd] IRP_MJ_CREATE without IRP_MJ_CLEANUP/CLOSE
>
>
> In my filter driver I am seeing IRP_MJ_CREATE for file objects but no
> IRP_MJ_CLOSE/IRP_MJ_CLEANUP. Under what circumstances is this possible ?
>
> The filter driver is a simple driver that keeps track of file objects
> created and destroyed and nothing else. After a while since the driver did
> not
> see CLEANUP/CLOSE, I am left with fileobject entries in my hash that are
> invalid or worse yet, entries that are valid but point to different target.
>
>
> -----
> Regds
>
>
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com