Getting full path name

I am using filespy for logging IRPs and fastio in the system. For every irp
i am getting file name except for IRP_MJ_CLEANUP. In some cases of clean up
IRP spygetfullpathname function returns c:[-=Error 0xc000000d Getting
Name=-] as file name. If you see filemon ver 3.3 code, they basically
maintains hash for file objects and maintain the filename in hash entry and
getting the filename for clean u irp. can you people recommend to use this
code in filespy in case we donot got name through spygetfullpathname.

Regards
Rohit

does this help…

http://www.osronline.com/showThread.cfm?link=91229

On 5/12/06, Rohit wrote:
>
> I am using filespy for logging IRPs and fastio in the system. For every
> irp i am getting file name except for IRP_MJ_CLEANUP. In some cases of clean
> up IRP spygetfullpathname function returns c:[-=Error 0xc000000d Getting
> Name=-] as file name. If you see filemon ver 3.3 code, they basically
> maintains hash for file objects and maintain the filename in hash entry and
> getting the filename for clean u irp. can you people recommend to use this
> code in filespy in case we donot got name through spygetfullpathname.
>
> Regards
>
> Rohit
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed
> to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank
> email to xxxxx@lists.osr.com
>



- amitr0

Hi all,

In the filespy code I see a lot of “Error Getting Filename”. The process of
getting a filename is :

In create they maintain a hashed list of FOs with filenames. In case of
other IRPs, it first tries th hashed list for the names, if it fails, then
it tries to get the name from the related FO, if it fails then it gets it
from the FS via a query.

My douobt is, if the FO is always sent down with the filename inprecreate,
then why would they ever need to fetch it from other sources like the FS. Is
it that the FO being sent for cleanup is a different FO?

Regards
Rohit

T.H. - sticky’s? This is what I was talking about. Once again, such magic.
Almost Deja-voo…

Always just a little different,
m

Rohit wrote:

Hi all,

In the filespy code I see a lot of “Error Getting Filename”. The
process of getting a filename is :

In create they maintain a hashed list of FOs with filenames. In case
of other IRPs, it first tries th hashed list for the names, if it
fails, then it tries to get the name from the related FO, if it fails
then it gets it from the FS via a query.

My douobt is, if the FO is always sent down with the filename
inprecreate, then why would they ever need to fetch it from other
sources like the FS. Is it that the FO being sent for cleanup is a
different FO?

Regards
Rohit

— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently
subscribed to ntfsd as: unknown lmsubst tag argument: ‘’ To
unsubscribe send a blank email to xxxxx@lists.osr.com

>My douobt is, if the FO is always sent down with the filename inprecreate,

FOs created internally by the FSD using IoCreateStreamFileObject never receive
any MJ_CREATE IRPs.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

IoCreateStreamFileObject* - these bypass filters on the open (and
possibly the cleanup)

Open by File ID - the “path” is not present in the file object

Rename - voila! The name has changed.

Hard links crossed with the above - your guess is as good as mine.

Processes without SeChangeNotifyPrivilege - you can’t retrieve the path
name.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rohit
Sent: Monday, May 15, 2006 9:02 AM
To: ntfsd redirect
Subject: [ntfsd] Getting full path name

Hi all,

In the filespy code I see a lot of “Error Getting Filename”. The process
of getting a filename is :

In create they maintain a hashed list of FOs with filenames. In case of
other IRPs, it first tries th hashed list for the names, if it fails,
then it tries to get the name from the related FO, if it fails then it
gets it from the FS via a query.

My douobt is, if the FO is always sent down with the filename
inprecreate, then why would they ever need to fetch it from other
sources like the FS. Is it that the FO being sent for cleanup is a
different FO?

Regards
Rohit

— Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17 You are currently subscribed
to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com

I observed in filespy their are some create IRPS followed by their cleanup
irp where both of them donot have file name in their FileObject

What could be the possible reasons for that . Below are the few lines from
filespy code

//
// CASE 1: This FileObject refers to a Volume open. Either the
// flag is set or no filename is specified.
//

if (FlagOn( FileObject->Flags, FO_VOLUME_OPEN ) ||
(FlagOn( LookupFlags, NLFL_IN_CREATE ) &&
(FileObject->FileName.Length == 0) &&
(FileObject->RelatedFileObject == NULL))) {

//
// We’ve already copied the VolumeName so just return.
//

}

Is it neccessary whenever above condition holds true then fileobject refers
to volume open. Or it might be possible in other case as well

Regards
Rohit

>I observed in filespy their are some create IRPS followed by their cleanup

irp where both of them donot have file name in their FileObject

File name is present in the file object only in pre-create path. It is not
guaranteed to be valid after.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com