problems in listing a Directory

OSR_Community_User · July 5, 2001, 5:13am

Hi,

We are facing two problems when we open/list a directory on a remote
share.

After the directory listing is done in MyFSDquerydirectory, My FSD
recieves MYFSDCreate calls for the DIR with NtCreateParams.Createoptions
set to 0x00000000 and NtCreateParams.FileAttributes also set to zero. The
Filename does not contain a trailing backslash in these calls.

We process these calls and return FILE_OPENED, these are followed by
another MYFSDCreate call with NtCreateParams.createoptions set to
0x00000860 i.e FILE_NON_DIRECORY_FILE flag set.

Why I am recieving these calls and how should I handle these calls when the
createoptions and the attributes are set to 0x00000000??

The second problem is my FSD recieves MyFSDCreate calls for the
DIR\desktop.ini(for the Folders customization details).

My current MyFSDCreate implementation makes lookup for this file and fails,
as the file does not exist on the remote directory.

I want to avoid these lookups for the DIR\desktop.ini files in MyFSDCreate
and
return before doing the lookup for the file.

Is there any flags or attributes we can use to know about such calls and
return?.

Please Help.

TIA.
Ruk

You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · July 5, 2001, 12:06pm

You might resend this to NTFSD. - Eric

-----Original Message-----
From: Kotikalapudi, Rukmini [mailto:xxxxx@india.ingr.com]
Sent: Thursday, July 05, 2001 2:14 AM
To: Kernel Debugging Interest List
Subject: [windbg] problems in listing a Directory

Hi,

We are facing two problems when we open/list a directory on a remote
share.

After the directory listing is done in MyFSDquerydirectory, My FSD
recieves MYFSDCreate calls for the DIR with
NtCreateParams.Createoptions set to 0x00000000 and
NtCreateParams.FileAttributes also set to zero. The Filename does not
contain a trailing backslash in these calls.

We process these calls and return FILE_OPENED, these are followed by
another MYFSDCreate call with NtCreateParams.createoptions set to
0x00000860 i.e FILE_NON_DIRECORY_FILE flag set.

Why I am recieving these calls and how should I handle these calls when
the createoptions and the attributes are set to 0x00000000??

The second problem is my FSD recieves MyFSDCreate calls for the
DIR\desktop.ini(for the Folders customization details).

My current MyFSDCreate implementation makes lookup for this file and
fails, as the file does not exist on the remote directory.

I want to avoid these lookups for the DIR\desktop.ini files in
MyFSDCreate and
return before doing the lookup for the file.

Is there any flags or attributes we can use to know about such calls and
return?.

Please Help.

TIA.
Ruk

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

OSR_Community_User · July 9, 2001, 2:39pm

This combination would indicate an attempt to supersede (since the upper 8
bits of the options are the disposition) and an indication that the newly
“superseded” file will be clean. Your return information (FILE_OPENED)
really doesn’t make much sense, since you were asked to supersede it
(normally you’d return FILE_SUPERSEDED, right?)

FILE_NON_DIRECTORY_FILE follows immediately from the fact that you just
superseded - you can only supersede a regular file, not a directory. Since
the “new” file didn’t specify that it was a directory (attributes were zero)
it had best not be a directory.

As for “desktop.ini” this isn’t a concept of the kernel level - it is an
attribute of the desktop shell running up in user mode. They are using the
standard API, so there is no special flag or attribute built into the OS for
recognizing this. Except the name.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Kotikalapudi, Rukmini [mailto:xxxxx@india.ingr.com]
Sent: Thursday, July 05, 2001 5:14 AM
To: Kernel Debugging Interest List
Subject: [windbg] problems in listing a Directory