Just wondering,
What, exactly, are those directory entries “.” and “…” ? Yes, I
know what they do, but what are they? When I query for directory
information for a directory (ZwQueryDirectoryFile), they are
indistinguishable from a ‘normal’ directory entry as far as I can tell. If
I try to ‘open’ them ZwCreateFile returns ‘STATUS_OBJECT_NAME_INVALID’.
When enumerating directories, if I wish to avoid them, I do so with
a string compare. That works, but I’m wondering, are they some sort of
‘special’ type that I’m not aware of? Is there any other way to distinguish
them from ‘normal’ directory entries other than a string compare on the name
field of their FILE_DIRECTORY_INFORMATION structure?
Thanks,
Joel
“.” and “…”. has information about current directory and … has information about its parent.
----- Original Message -----
From: Smith, Joel
To: File Systems Developers
Sent: Tuesday, March 28, 2000 11:40 AM
Subject: [ntfsd] “.” and “…”
Just wondering,
What, exactly, are those directory entries “.” and “…” ? Yes, I know what they do, but what are they? When I query for directory information for a directory (ZwQueryDirectoryFile), they are indistinguishable from a ‘normal’ directory entry as far as I can tell. If I try to ‘open’ them ZwCreateFile returns ‘STATUS_OBJECT_NAME_INVALID’.
When enumerating directories, if I wish to avoid them, I do so with a string compare. That works, but I’m wondering, are they some sort of ‘special’ type that I’m not aware of? Is there any other way to distinguish them from ‘normal’ directory entries other than a string compare on the name field of their FILE_DIRECTORY_INFORMATION structure?
Thanks,
Joel
Yes, I understand what the semantics are, but I’m wondering if they are
instances of some special case directory type. I ask because it seems
strange that they show up in the results of a ZwQueryDirectoryFile query
with the ‘FILE_ATTRIBUTE_DIRECTORY’ attribute set (as if they were normal
directories), and yet, they cannot be ‘opened’ with a call to ZwCreateFile
like a normal directory entry.
I’m just curious because if they are an instance of some special case
directory type, then there is some special case directory type that I don’t
know about. If they are just ‘magic’ names which don’t map to an underlying
file system object, then it is truly irrelevant.
Thanks,
Joel
-----Original Message-----
From: Raja [mailto:xxxxx@hotmail.com]
Sent: Tuesday, March 28, 2000 3:27 PM
To: File Systems Developers
Subject: [ntfsd] Re: “.” and “…”
. has information about current directory and … has information about its
parent.
----- Original Message -----
From: Smith, Joel mailto:xxxxx
To: File Systems mailto:xxxxx Developers
Sent: Tuesday, March 28, 2000 11:40 AM
Subject: [ntfsd] “.” and “…”
Just wondering,
What, exactly, are those directory entries “.” and “…” ? Yes, I
know what they do, but what are they? When I query for directory
information for a directory (ZwQueryDirectoryFile), they are
indistinguishable from a ‘normal’ directory entry as far as I can tell. If
I try to ‘open’ them ZwCreateFile returns ‘STATUS_OBJECT_NAME_INVALID’.
When enumerating directories, if I wish to avoid them, I do so with
a string compare. That works, but I’m wondering, are they some sort of
‘special’ type that I’m not aware of? Is there any other way to distinguish
them from ‘normal’ directory entries other than a string compare on the name
field of their FILE_DIRECTORY_INFORMATION structure?
Thanks,
Joel</mailto:xxxxx></mailto:xxxxx>
Actually, what they map to is a function of the file system. NTFS (as I
recall) really does synthetically generate these names, so they don’t map to
an underlying file system object. I don’t recall what FAT and CDFS do, but
since that code is in the IFS kit it should be simple to research.
Normally “…” and “.” are removed from the path long before it hits an NT
file system, so they are really irrelevant, regardless of how they are
implemented by the underlying FSD.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Tuesday, March 28, 2000 3:59 PM
To: File Systems Developers
Subject: [ntfsd] Re: “.” and “…”
Yes, I understand what the semantics are, but I’m wondering if they are
instances of some special case directory type. I ask because it seems
strange that they show up in the results of a ZwQueryDirectoryFile query
with the ‘FILE_ATTRIBUTE_DIRECTORY’ attribute set (as if they were normal
directories), and yet, they cannot be ‘opened’ with a call to ZwCreateFile
like a normal directory entry.
I’m just curious because if they are an instance of some special case
directory type, then there is some special case directory type that I don’t
know about. If they are just ‘magic’ names which don’t map to an underlying
file system object, then it is truly irrelevant.
Thanks,
Joel
-----Original Message-----
From: Raja [mailto:xxxxx@hotmail.com]
Sent: Tuesday, March 28, 2000 3:27 PM
To: File Systems Developers
Subject: [ntfsd] Re: “.” and “…”
. has information about current directory and … has information about its
parent.
----- Original Message -----
From: Smith, Joel mailto:xxxxx
To: File Systems mailto:xxxxx Developers
Sent: Tuesday, March 28, 2000 11:40 AM
Subject: [ntfsd] “.” and “…”
Just wondering,
What, exactly, are those directory entries “.” and “…” ? Yes, I
know what they do, but what are they? When I query for directory
information for a directory (ZwQueryDirectoryFile), they are
indistinguishable from a ‘normal’ directory entry as far as I can tell. If
I try to ‘open’ them ZwCreateFile returns ‘STATUS_OBJECT_NAME_INVALID’.
When enumerating directories, if I wish to avoid them, I do so with
a string compare. That works, but I’m wondering, are they some sort of
‘special’ type that I’m not aware of? Is there any other way to distinguish
them from ‘normal’ directory entries other than a string compare on the name
field of their FILE_DIRECTORY_INFORMATION structure?
Thanks,
Joel</mailto:xxxxx></mailto:xxxxx></http:>
“.” and “…”>‘special’ type that I’m not aware of? Is there any other way
to distinguish
them from ‘normal’ directory entries other than a string compare on the
name field of their FILE_DIRECTORY_INFORMATION structure?
No, especially if the FS supports true hardlinks. In this case, . and … are
usually exist on disk & are just ordinary hardlinks - to itself and to the
parent.
max
> an underlying file system object. I don’t recall what FAT and CDFS do,
but
since that code is in the IFS kit it should be simple to research.
FAT has these entries on-disk.
Normally “…” and “.” are removed from the path long before it hits an NT
file system, so they are really irrelevant, regardless of how they are
implemented by the underlying FSD.
Are you sure IO manager will do something with the tail of the path after
the
device name?
Max
Max,
Thanks for looking up the FAT implementation. I thought that was the case,
but I don’t like to say things unless I’m convinced they are true.
Actually I’m quite sure the I/O Manager does NOT do anything with the tail
of the path. The “normally” here was really dealing with subsystem
behavior. Neither the I/O Manager nor the Object Manager appear to mangle
the names beyond the expected operations (reparse points, symbolic links.)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, March 29, 2000 8:59 AM
To: File Systems Developers
Subject: [ntfsd] Re: “.” and “…”
an underlying file system object. I don’t recall what FAT and CDFS do,
but
since that code is in the IFS kit it should be simple to research.
FAT has these entries on-disk.
Normally “…” and “.” are removed from the path long before it hits an NT
file system, so they are really irrelevant, regardless of how they are
implemented by the underlying FSD.
Are you sure IO manager will do something with the tail of the path after
the
device name?
Max
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> Max,
Thanks for looking up the FAT implementation. I thought that was the
case,
but I don’t like to say things unless I’m convinced they are true.
UNIX filesystems also have . and … on disk - they are implemented as usual
hardlinks. See the link count field for any directory which have subdirs.
Max