problem with FSD: "type"ing files at the command prompt

I start with a freshly formatted volume. I create two files by "echo"ing
text and piping the output into the files. I “type” the first file, and i
see the contents of both files in the output. Both files are actually
opened and read with IRPs. These steps can be repeated with more than two
files, and the contents of all files are shown.

This is the output from the command prompt:

C:\>e:

E:\>dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:\

File Not Found

E:\>echo abc>abc

E:\>echo abcd>abcd

E:\>type abc
abc
abcd

E:\>dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:\

03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:\>

Has anyone experienced this behavior or can anyone tell me where to start
looking for the problem? Thanks,
Jeremy

Which file system? Have you tried it on other file systems? If I had
to guess, I would suspect a shell bug…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 2:23 PM
To: ntfsd redirect
Subject: [ntfsd] problem with FSD: "type"ing files at the command prompt

I start with a freshly formatted volume. I create two files by
"echo"ing text and piping the output into the files. I “type” the first
file, and i see the contents of both files in the output. Both files
are actually opened and read with IRPs. These steps can be repeated
with more than two files, and the contents of all files are shown.

This is the output from the command prompt:

C:\>e:

E:\>dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:\

File Not Found

E:\>echo abc>abc

E:\>echo abcd>abcd

E:\>type abc
abc
abcd

E:\>dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:\

03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:\>

Has anyone experienced this behavior or can anyone tell me where to
start looking for the problem? Thanks, Jeremy


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

The file system is new, and this is the first port to a desktop Windows OS. For the record, it’s called Reliance (reliance.datalight.com) and has been ported already to Windows CE, VxWorks, and DOS.

None of the other FSDs do this (I’ve tried FastFAT, NTFS), so I must be doing something differently. Below is some output from my FSD. It’s a little cryptic, but I’ll do my best to explain. This output is from typing “type abc” at the cmd.exe command prompt, then closing the cmd.exe windows (to close handles).

[1] function: replace rel… with IRP_MJ_… to get IRP
[2] status value returned (and completed if not pending)
[3] filename: calculated from parameters including irpsp->fileobject->filename, irpsp->fileobject->relatedfileobject->filename
[4+] parameters: depends on the IRP

[1] [2] [3] [4+]
-relCreate 0x00000000 \ 0x00000001 0x01000021
-relQueryDirectory 0x00000000 \ 1 entries returned
-relCreate 0x00000000 \abc 0x00000001 0x01200000 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abc FileBasicInformation
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relCreate 0x00000000 \abc 0x00000001 0x01000060 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abc FileStandardInformation
-relRead 0x00000000 \abc
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relQueryDirectory 0x00000000 \ 1 entries returned
-relCreate 0x00000000 \abcd 0x00000001 0x01000060 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abcd FileStandardInformation
-relRead 0x00000000 \abcd
-relCleanup 0x00000000 \abcd
-relClose 0x00000000 \abcd
-relQueryDirectory 0x80000006 \ 0 entries returned
-relCleanup 0x00000000 \
-relClose 0x00000000 \

Does anything in the log above look wrong? Thanks,

Jeremy

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Which file system? Have you tried it on other file systems? If I had
to guess, I would suspect a shell bug…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 2:23 PM
To: ntfsd redirect
Subject: [ntfsd] problem with FSD: "type"ing files at the command prompt

I start with a freshly formatted volume. I create two files by
"echo"ing text and piping the output into the files. I “type” the first
file, and i see the contents of both files in the output. Both files
are actually opened and read with IRPs. These steps can be repeated
with more than two files, and the contents of all files are shown.

This is the output from the command prompt:

C:>e:

E:>dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
File Not Found

E:&gt;echo abc>abc

E:&gt;echo abcd>abcd

E:&gt;type abc
abc
abcd

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:&gt;

Has anyone experienced this behavior or can anyone tell me where to
start looking for the problem? Thanks, Jeremy


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

Aha! That’s an added bit of information - this is your file system.

I’d guess you aren’t handling cleanup/close properly. How do you
distinguish different open instances of files from one another?

It also looks like you haven’t added cache support yet (which is why you
see cleanup/close in sequence in your trace, since the cache isn’t
keeping the files open.) While this is not the issue in this case, it
is going to end up being an issue for you “down the road” as you begin
to try using your file system with Windows.

From the trace you give, I don’t see a windows error here. What I do
see that surprises me is that your create’s succeed, even though the
caller appears to have specified FILE_OPEN (which means the create
operation should fail because the file does not exist). But you
indicated this was a freshly formatted volume, so I don’t know why an
open would succeed in this case.

Welcome to the crazy world of Windows…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 5:44 PM
To: ntfsd redirect
Subject: Re:[ntfsd] problem with FSD: "type"ing files at the command
prompt

The file system is new, and this is the first port to a desktop Windows
OS. For the record, it’s called Reliance (reliance.datalight.com) and
has been ported already to Windows CE, VxWorks, and DOS.

None of the other FSDs do this (I’ve tried FastFAT, NTFS), so I must be
doing something differently. Below is some output from my FSD. It’s a
little cryptic, but I’ll do my best to explain. This output is from
typing “type abc” at the cmd.exe command prompt, then closing the
cmd.exe windows (to close handles).

[1] function: replace rel… with IRP_MJ_… to get IRP
[2] status value returned (and completed if not pending)
[3] filename: calculated from parameters including
irpsp->fileobject->filename,
irpsp->fileobject->relatedfileobject->filename
[4+] parameters: depends on the IRP

[1] [2] [3]
[4+]
-relCreate 0x00000000 \
0x00000001 0x01000021
-relQueryDirectory 0x00000000 \
1 entries returned
-relCreate 0x00000000 \abc
0x00000001 0x01200000 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abc
FileBasicInformation
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relCreate 0x00000000 \abc
0x00000001 0x01000060 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abc
FileStandardInformation
-relRead 0x00000000 \abc
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relQueryDirectory 0x00000000 \
1 entries returned
-relCreate 0x00000000 \abcd
0x00000001 0x01000060 … pRelatedFileObject: \
-relQueryInformation 0x00000000 \abcd
FileStandardInformation
-relRead 0x00000000 \abcd
-relCleanup 0x00000000 \abcd
-relClose 0x00000000 \abcd
-relQueryDirectory 0x80000006 \
0 entries returned
-relCleanup 0x00000000 \
-relClose 0x00000000 \

Does anything in the log above look wrong? Thanks,

Jeremy

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Which file system? Have you tried it on other file systems? If I had
to guess, I would suspect a shell bug…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 2:23 PM
To: ntfsd redirect
Subject: [ntfsd] problem with FSD: "type"ing files at the command prompt

I start with a freshly formatted volume. I create two files by
"echo"ing text and piping the output into the files. I “type” the first
file, and i see the contents of both files in the output. Both files
are actually opened and read with IRPs. These steps can be repeated
with more than two files, and the contents of all files are shown.

This is the output from the command prompt:

C:&gt;e:

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
File Not Found

E:&gt;echo abc>abc

E:&gt;echo abcd>abcd

E:&gt;type abc
abc
abcd

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:&gt;

Has anyone experienced this behavior or can anyone tell me where to
start looking for the problem? Thanks, Jeremy


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


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

The output is only from the very last part of the test, where I “type” the file and see the contents of both files. So the files abc and abcd do exist.

You’re right, I havn’t added cache support yet. I determined that this was not necessary at the moment, and chose to implement the more foundational components of the FSD before persuing beasts like cache support.

Looking at the output, knowing that it’s just the “type” portion of the test and the files already exist, does anything stick out?

Thanks,
Jeremy
“Tony Mason” wrote in message news:xxxxx@ntfsd…
Aha! That’s an added bit of information - this is your file system.

I’d guess you aren’t handling cleanup/close properly. How do you distinguish different open instances of files from one another?

It also looks like you haven’t added cache support yet (which is why you see cleanup/close in sequence in your trace, since the cache isn’t keeping the files open.) While this is not the issue in this case, it is going to end up being an issue for you “down the road” as you begin to try using your file system with Windows.

From the trace you give, I don’t see a windows error here. What I do see that surprises me is that your create’s succeed, even though the caller appears to have specified FILE_OPEN (which means the create operation should fail because the file does not exist). But you indicated this was a freshly formatted volume, so I don’t know why an open would succeed in this case.

Welcome to the crazy world of Windows…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 5:44 PM
To: ntfsd redirect
Subject: Re:[ntfsd] problem with FSD: "type"ing files at the command prompt

The file system is new, and this is the first port to a desktop Windows OS. For the record, it’s called Reliance (reliance.datalight.com) and has been ported already to Windows CE, VxWorks, and DOS.

None of the other FSDs do this (I’ve tried FastFAT, NTFS), so I must be doing something differently. Below is some output from my FSD. It’s a little cryptic, but I’ll do my best to explain. This output is from typing “type abc” at the cmd.exe command prompt, then closing the cmd.exe windows (to close handles).

[1] function: replace rel… with IRP_MJ_… to get IRP
[2] status value returned (and completed if not pending)
[3] filename: calculated from parameters including irpsp->fileobject->filename, irpsp->fileobject->relatedfileobject->filename
[4+] parameters: depends on the IRP

[1] [2] [3] [4+]
-relCreate 0x00000000 \ 0x00000001 0x01000021
-relQueryDirectory 0x00000000 \ 1 entries returned
-relCreate 0x00000000 \abc 0x00000001 0x01200000 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abc FileBasicInformation
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relCreate 0x00000000 \abc 0x00000001 0x01000060 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abc FileStandardInformation
-relRead 0x00000000 \abc
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relQueryDirectory 0x00000000 \ 1 entries returned
-relCreate 0x00000000 \abcd 0x00000001 0x01000060 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abcd FileStandardInformation
-relRead 0x00000000 \abcd
-relCleanup 0x00000000 \abcd
-relClose 0x00000000 \abcd
-relQueryDirectory 0x80000006 \ 0 entries returned
-relCleanup 0x00000000 <br> -relClose 0x00000000 <br>
Does anything in the log above look wrong? Thanks,

Jeremy

“Tony Mason” wrote in message news:xxxxx@ntfsd…
Which file system? Have you tried it on other file systems? If I had
to guess, I would suspect a shell bug…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 2:23 PM
To: ntfsd redirect
Subject: [ntfsd] problem with FSD: "type"ing files at the command prompt

I start with a freshly formatted volume. I create two files by
"echo"ing text and piping the output into the files. I “type” the first
file, and i see the contents of both files in the output. Both files
are actually opened and read with IRPs. These steps can be repeated
with more than two files, and the contents of all files are shown.

This is the output from the command prompt:

C:&gt;e:

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
File Not Found

E:&gt;echo abc>abc

E:&gt;echo abcd>abcd

E:&gt;type abc
abc
abcd

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:&gt;

Has anyone experienced this behavior or can anyone tell me where to
start looking for the problem? Thanks, Jeremy


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


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

Nothing sticks out from the information you have provided; of course,
giving half of the trace is a bit unfair…

So, you need to determine where the error is:

  • In the original write of data (that is, does the data get written to
    the wrong file), if so review your code for distinguishing what is being
    written.
  • In the subsequent read of the data (that is, does the data get read
    from the wrong file).

Does the data in the first file appear correctly if you type it out
before writing to the second file?

There’s clearly a sequencing problem, but I suspect that only seeing a
piece of the trace and not the entire trace itself nobody on the list is
going to be able to suggest something “obvious”.

Wish I could offer more guidance.

Regards,

Tony

P.S. Have you used filespy or filemon to capture the entire trace? Or
are the trace records you spit out from your own FSD?


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeremy Sherrill
Sent: Monday, March 01, 2004 6:25 PM
To: ntfsd redirect
Subject: Re:[ntfsd] problem with FSD: "type"ing files at the command
prompt

The output is only from the very last part of the test, where I “type”
the file and see the contents of both files. So the files abc and abcd
do exist.

You’re right, I havn’t added cache support yet. I determined that this
was not necessary at the moment, and chose to implement the more
foundational components of the FSD before persuing beasts like cache
support.

Looking at the output, knowing that it’s just the “type” portion of the
test and the files already exist, does anything stick out?

Thanks,
Jeremy

“Tony Mason” wrote in message
news:xxxxx@ntfsd…
Aha! That’s an added bit of information - this is your file
system.

I’d guess you aren’t handling cleanup/close properly. How do
you distinguish different open instances of files from one another?

It also looks like you haven’t added cache support yet (which is
why you see cleanup/close in sequence in your trace, since the cache
isn’t keeping the files open.) While this is not the issue in this
case, it is going to end up being an issue for you “down the road” as
you begin to try using your file system with Windows.

From the trace you give, I don’t see a windows error here. What
I do see that surprises me is that your create’s succeed, even though
the caller appears to have specified FILE_OPEN (which means the create
operation should fail because the file does not exist). But you
indicated this was a freshly formatted volume, so I don’t know why an
open would succeed in this case.

Welcome to the crazy world of Windows…

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 Jeremy Sherrill
Sent: Monday, March 01, 2004 5:44 PM
To: ntfsd redirect
Subject: Re:[ntfsd] problem with FSD: "type"ing files at the
command prompt

The file system is new, and this is the first port to a desktop
Windows OS. For the record, it’s called Reliance
(reliance.datalight.com) and has been ported already to Windows CE,
VxWorks, and DOS.

None of the other FSDs do this (I’ve tried FastFAT, NTFS), so I
must be doing something differently. Below is some output from my FSD.
It’s a little cryptic, but I’ll do my best to explain. This output is
from typing “type abc” at the cmd.exe command prompt, then closing the
cmd.exe windows (to close handles).

[1] function: replace rel… with IRP_MJ_… to get IRP
[2] status value returned (and completed if not pending)
[3] filename: calculated from parameters including
irpsp->fileobject->filename,
irpsp->fileobject->relatedfileobject->filename
[4+] parameters: depends on the IRP

[1] [2] [3]
[4+]
-relCreate 0x00000000 <br>0x00000001 0x01000021
-relQueryDirectory 0x00000000 <br>1 entries returned
-relCreate 0x00000000 \abc
0x00000001 0x01200000 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abc
FileBasicInformation
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relCreate 0x00000000 \abc
0x00000001 0x01000060 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abc
FileStandardInformation
-relRead 0x00000000 \abc
-relCleanup 0x00000000 \abc
-relClose 0x00000000 \abc
-relQueryDirectory 0x00000000 <br>1 entries returned
-relCreate 0x00000000 \abcd
0x00000001 0x01000060 … pRelatedFileObject: <br> -relQueryInformation 0x00000000 \abcd
FileStandardInformation
-relRead 0x00000000 \abcd
-relCleanup 0x00000000 \abcd
-relClose 0x00000000 \abcd
-relQueryDirectory 0x80000006 <br>0 entries returned
-relCleanup 0x00000000 <br> -relClose 0x00000000 <br>
Does anything in the log above look wrong? Thanks,

Jeremy

“Tony Mason” wrote in message
news:xxxxx@ntfsd…
Which file system? Have you tried it on other file systems? If
I had
to guess, I would suspect a shell bug…

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 Jeremy
Sherrill
Sent: Monday, March 01, 2004 2:23 PM
To: ntfsd redirect
Subject: [ntfsd] problem with FSD: "type"ing files at the
command prompt

I start with a freshly formatted volume. I create two files by
"echo"ing text and piping the output into the files. I “type”
the first
file, and i see the contents of both files in the output. Both
files
are actually opened and read with IRPs. These steps can be
repeated
with more than two files, and the contents of all files are
shown.

This is the output from the command prompt:

C:&gt;e:

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
File Not Found

E:&gt;echo abc>abc

E:&gt;echo abcd>abcd

E:&gt;type abc
abc
abcd

E:&gt;dir
Volume in drive E is RELIANCE
Volume Serial Number is 0000-0000

Directory of E:<br>
03/01/2004 01:11 AM 5 abc
03/01/2004 01:11 AM 6 abcd
2 File(s) 11 bytes
0 Dir(s) 2,146,203,648 bytes free

E:&gt;

Has anyone experienced this behavior or can anyone tell me where
to
start looking for the problem? Thanks, Jeremy


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


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


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

I would suggest to check how you handle IRP_MJ_DIRECTORY_CONTROL.
It look like you returned both file names while being asked to return only
“abc”.
Semantics of handling IRP_MJ_DIRECTORY_CONTROL is quite obscure. I guess you
don’t handle the second IRP_MJ_DIRECTORY_CONTROL properly. When you process
second IRP_MJ_DIRECTORY_CONTROL you will not get name in
Parameters.QueryDirectory.FileName. You need to remember the name from the
first request in CCB and apply appropriate filtering when processing the
second IRP.

Alexei.

“Jeremy Sherrill” wrote in message
news:xxxxx@ntfsd…
> I start with a freshly formatted volume. I create two files by "echo"ing
> text and piping the output into the files. I “type” the first file, and i
> see the contents of both files in the output. Both files are actually
> opened and read with IRPs. These steps can be repeated with more than two
> files, and the contents of all files are shown.
>
> This is the output from the command prompt:
>
> C:&gt;e:
>
> E:&gt;dir
> Volume in drive E is RELIANCE
> Volume Serial Number is 0000-0000
>
> Directory of E:<br>>
> File Not Found
>
> E:&gt;echo abc>abc
>
> E:&gt;echo abcd>abcd
>
> E:&gt;type abc
> abc
> abcd
>
> E:&gt;dir
> Volume in drive E is RELIANCE
> Volume Serial Number is 0000-0000
>
> Directory of E:<br>>
> 03/01/2004 01:11 AM 5 abc
> 03/01/2004 01:11 AM 6 abcd
> 2 File(s) 11 bytes
> 0 Dir(s) 2,146,203,648 bytes free
>
> E:&gt;
>
>
> Has anyone experienced this behavior or can anyone tell me where to start
> looking for the problem? Thanks,
> Jeremy
>
>
>

> You’re right, I havn’t added cache support yet. I determined that

this was not necessary at the moment, and chose to implement
the more foundational components of the FSD before persuing beasts like cache support.

(A little off-topic) This is not good. If you will implement caching
later, you will have to rewrite (or redesign) some part of you code,
which will take you more time than if you wrote the cache support
at the beginning.

Sooner or later, you will have to support the caching mechanism,
as soon as you’ll run the first performance test for your FSD and any
of the FSD from Windows and will see that yours is much slower.

L.

Thank you Alexei, the problem was in fact in the handling of
IRP_MJ_DIRECTORY_CONTROL. Egg’s on my face this time, I was completely
ignoring the Parameters.QueryDirectory.FileName string. I had better read
the docs more carefully next time… Thanks again!

Jeremy

“Alexei Jelvis” wrote in message news:xxxxx@ntfsd…
> I would suggest to check how you handle IRP_MJ_DIRECTORY_CONTROL.
> It look like you returned both file names while being asked to return only
> “abc”.
> Semantics of handling IRP_MJ_DIRECTORY_CONTROL is quite obscure. I guess
you
> don’t handle the second IRP_MJ_DIRECTORY_CONTROL properly. When you
process
> second IRP_MJ_DIRECTORY_CONTROL you will not get name in
> Parameters.QueryDirectory.FileName. You need to remember the name from the
> first request in CCB and apply appropriate filtering when processing the
> second IRP.
>
> Alexei.
>
> “Jeremy Sherrill” wrote in message
> news:xxxxx@ntfsd…
> > I start with a freshly formatted volume. I create two files by
"echo"ing
> > text and piping the output into the files. I “type” the first file, and
i
> > see the contents of both files in the output. Both files are actually
> > opened and read with IRPs. These steps can be repeated with more than
two
> > files, and the contents of all files are shown.
> >
> > This is the output from the command prompt:
> >
> > C:&gt;e:
> >
> > E:&gt;dir
> > Volume in drive E is RELIANCE
> > Volume Serial Number is 0000-0000
> >
> > Directory of E:<br>> >
> > File Not Found
> >
> > E:&gt;echo abc>abc
> >
> > E:&gt;echo abcd>abcd
> >
> > E:&gt;type abc
> > abc
> > abcd
> >
> > E:&gt;dir
> > Volume in drive E is RELIANCE
> > Volume Serial Number is 0000-0000
> >
> > Directory of E:<br>> >
> > 03/01/2004 01:11 AM 5 abc
> > 03/01/2004 01:11 AM 6 abcd
> > 2 File(s) 11 bytes
> > 0 Dir(s) 2,146,203,648 bytes free
> >
> > E:&gt;
> >
> >
> > Has anyone experienced this behavior or can anyone tell me where to
start
> > looking for the problem? Thanks,
> > Jeremy
> >
> >
> >
>
>
>