Does anyone know whether there is a (documented or folklore) requirement
that the response(s) from an FSD to IRP_MN_QUERY_DIRECTORY should include
entries for the “.” and “…” directories? Can callers legitimately expect
them to be there? And if so, are they constrained to be returned first?
My driver does not, and I have just found my first application (in three
years) that failed because of the omission of these two pseudo-directories.
And although the application writers said that their code was in the wrong,
I have this niggling doubt.
Thanks
Brian
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
It would be an excellent idea. I do not believe it is documented (yet),
but then again you just ran into the Reason.
Windows FS attempt to follow these rules:
./… in non-root
nothing in root
which basically derive from the physical structure of FAT. Some FS
require . and/or … to be synthesized since they don’t have physical
directory entries which correspond to them. As an FS, however, you will
never need to process ./… since they are handled via a textual
transformation in the Win32/Rtl layer.
-----Original Message-----
From: xxxxx@iOra.com [mailto:xxxxx@iOra.com]
Sent: Tuesday, August 21, 2001 2:42 AM
To: File Systems Developers
Subject: [ntfsd] Are directories “.” and “…” required?
Does anyone know whether there is a (documented or folklore) requirement
that the response(s) from an FSD to IRP_MN_QUERY_DIRECTORY should
include
entries for the “.” and “…” directories? Can callers legitimately
expect
them to be there? And if so, are they constrained to be returned first?
My driver does not, and I have just found my first application (in three
years) that failed because of the omission of these two
pseudo-directories.
And although the application writers said that their code was in the
wrong,
I have this niggling doubt.
Thanks
Brian
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Does anyone know whether there is a (documented or folklore) requirement
that the response(s) from an FSD to IRP_MN_QUERY_DIRECTORY should include
entries for the “.” and “…” directories? Can callers legitimately expect
them to be there? And if so, are they constrained to be returned first?
My driver does not, and I have just found my first application (in three
years) that failed because of the omission of these two
pseudo-directories.
And although the application writers said that their code was in the
wrong,
I have this niggling doubt.
I don’t know on official MS’s requirements, but at least FASTFAT does
support “.” and “…”.
Looks like that their support is a must, better to return them as first 2
entries.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>directory entries which correspond to them. As an FS, however, you will
never need to process ./… since they are handled via a textual
transformation in the Win32/Rtl layer.
Do you mean the path traversing?
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Yes.
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, August 22, 2001 10:20 AM
To: File Systems Developers
Subject: [ntfsd] RE: Are directories “.” and “…” required?
directory entries which correspond to them. As an FS, however, you will
never need to process ./… since they are handled via a textual
transformation in the Win32/Rtl layer.
Do you mean the path traversing?
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com