FAT filesystem creates them in every directory(except root). I’ve not seen the NTFS specification, but it appears to me that NTFS too creates them for every non-root directory.
What bemused me was the behavior on exFAT file system. exFAT specification does not have the provision for creating these entries, but Microsoft’s implementation of exFAT spec i.e. exFAT.sys returns those entries when a directory listing is made on non-root directory.
Yes, it’s trivial for a filesystem to populate the system buffer(during QueryDirectory) with ‘.’ and ‘…’ even when they are not present on disk, but I wonder why do they have to list them,in the first place.
Does these entries bear any tremendous significance. Is their absence has something to do with the compatibility of certain applications/abnormal behaviour of any sort? Or can it be said that a particular filesystem has absolute freedom when it comes to supporting(or not supporting) these entries?
In the IFS test suite, I did not find any such test which checks for the presence of these entires, so windows logo does not depend upon it , I suppose.
They have their usefulness. The single refers to the current directory and
the double refers to the parent. It would be hard to use relative paths
without those semantics. Whether they MUST be present is a design decision
influenced by history, I believe. P.S. there is no NTFS Specification
except probably internal documents at Microsoft that they may share with
those who license them.
wrote in message news:xxxxx@ntfsd…
> FAT filesystem creates them in every directory(except root). I’ve not seen
> the NTFS specification, but it appears to me that NTFS too creates them
> for every non-root directory.
> What bemused me was the behavior on exFAT file system. exFAT specification
> does not have the provision for creating these entries, but Microsoft’s
> implementation of exFAT spec i.e. exFAT.sys returns those entries when a
> directory listing is made on non-root directory.
> Yes, it’s trivial for a filesystem to populate the system buffer(during
> QueryDirectory) with ‘.’ and ‘…’ even when they are not present on disk,
> but I wonder why do they have to list them,in the first place.
> Does these entries bear any tremendous significance. Is their absence has
> something to do with the compatibility of certain applications/abnormal
> behaviour of any sort? Or can it be said that a particular filesystem has
> absolute freedom when it comes to supporting(or not supporting) these
> entries?
> In the IFS test suite, I did not find any such test which checks for the
> presence of these entires, so windows logo does not depend upon it , I
> suppose.
>
>
>
>
Things like cd…\SomeFolderInParent will not work in case the FS does not support them. So all those batch script will stop functioning.
> Things like cd…\SomeFolderInParent will not work in case the FS does not support them.
Absolutely not so.
“.” and “…” can be processed by the FSD without any on-disk support for them, just using the hardcoded logic in the pathname parser.
For me, on-disk “.” and “…” in FAT is some strange remnant of the old MS-DOS days.
According to what I know, NTFS does not have these items on disk, and FAT does not have them in the root directory.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
In our own file systems kit, we actually match those semantics. While
not an onerous amount of work, some applications do depend on this
working in this particular way. I suspect that’s the reason they do it
in EXFAT - deviating from these semantics means things just won’t work
the way you expect otherwise.
Note that “…” in paths does not generally work at file systems level -
it’s parsed out before that point (although note there is now an FsRtl
function to collapse them out - FsRtlRemoveDotsFromPath.)
Tony
OSR
>>“.” and “…” can be processed by the FSD without any on-disk support for them, just using the hardcoded logic in the pathname parser.
Ok, So the parse method registerd for the file object type by IoManager with Object manager is responsible for it, but shouldn’t that be implemented with the help of underlying FS?
I wrote.
>Ok, So the parse method registerd for the file object type by IoManager with Object manager is responsible for it, but shouldn’t that be implemented with the help of underlying FS?
Useless thought, please ignore :-). It should be with the application responsibility.
Thanks
aditya
As a small divert into history. I always thought it was a shame that later
operating systems didn’t follow VMS and have a separate facility (in
supervisor mode, so not strictly kernel) to do all the funky stuff with name
handling. Broadly speaking the filesystem didn’t case about names, just
directory contents, but neither did the application it could just send down
DUA$1:[fooo.bar.-…]*.fred and then RMS would serve the names up. None of
this “/s” or “app `find . -name “/foo/bar/…/” -print’” nonsense.
/r
wrote in message news:xxxxx@ntfsd…
>I wrote.
>>>Ok, So the parse method registerd for the file object type by IoManager
>>>with Object manager is responsible for it, but shouldn’t that be
>>>implemented with the help of underlying FS?
>
> Useless thought, please ignore :-). It should be with the application
> responsibility.
>
> Thanks
> aditya
>
>Things like cd…\SomeFolderInParent will not work in case the FS does not support them
Myth. Before writing this post, I checked the behavior (by using procmon, and my prototype file system) of cmd. File system does not receive any DOT or DOTDOT.
some applications do depend on this working in this particular way
I changed the prototype file system and omitted the creation of these entries(in fact, I made entires in root dir but not for any other directory), but did not observe abnormal behavior of some sort. However, I did not test the compatibility of many applications with this modified FS.
These semantics can surely be the backbone of some applications. Application world is vast; I managed to find some recovery application developers who rely on these entries.
>>Myth. Before writing this post, I checked the behavior (by using procmon, and my prototype file system) of cmd. File system does not receive any DOT or DOTDOT.
I did not state that there will be some IRP . and … in file path. I read that IoManager along with the FS provides a parse routine for file object, now if this parse routine is responsibility of FS than things will not work in your FS but if IO manager handles it, they will.
>It should be with the application responsibility.
I have checked its not, so before creating an IRP, its resolving the relative name to exact name. I was correct with my first assumption.
>some applications do depend on this working in this particular way
We initially didn’t generate them in our FileSystem, but after some issues with applications we started to emit them. The main issue was with Save as/Open common dialogs IIRC. One coudn’t enter into directory, which had not have at least one entry. But it was several years ago, so maybe it was addressed in some SP (on XP).
Bronislav Gabrhelik
>responsible for it, but shouldn’t that be implemented with the help of underlying FS?
FSD should support this parsing, but this does not require on-disk dirents of “.” and “…”.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
FWIW, I’ve don’t recall our filesystem ever seeing a request to lookup a
component of “.” or “…”.
I think this is by design. The IoManager might be in a better position
handle “…” in particular because one volume could be mounted in multiple
places (eg. c:\fsdmountpoint1, c:\fsdmountpoint2, and f:), and “…” has a
different meaning in each context, which I’m not entirely sure how the FSD
would discern.
So I don’t think the FSD needs to parse “.”, “…” in paths.
I do find, though, that people like to see “.” and “…” in subdirectory
listings.
If the above is correct, whether the directory listings contain “.”, “…”
has absolutely zero impact on actually using paths with them, just gives
people a cue that they’re using a subdir. (ie. “f:\a..\a2” is opened as
“f:\a2” with our FS even when not generating or parsing “…” entries.)
Jeff
On Tue, Nov 3, 2009 at 3:04 AM, wrote:
> >Things like cd…\SomeFolderInParent will not work in case the FS does not
> support them
>
> Myth. Before writing this post, I checked the behavior (by using procmon,
> and my prototype file system) of cmd. File system does not receive any DOT
> or DOTDOT.
>
>
> >some applications do depend on this working in this particular way
>
> I changed the prototype file system and omitted the creation of these
> entries(in fact, I made entires in root dir but not for any other
> directory), but did not observe abnormal behavior of some sort. However, I
> did not test the compatibility of many applications with this modified FS.
> These semantics can surely be the backbone of some applications.
> Application world is vast; I managed to find some recovery application
> developers who rely on these entries.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
What’s fun is when you traverse mount points. The root directory of the
new volume won’t show “.” or “…” entries. Thus, this becomes a simple
technique for noticing when you’ve walked across a mount point. I
wouldn’t be surprised to find out someone else has noticed this and used
this characteristic to detect them, since checking every directory to
see if it is a mount point would be rather expensive (and the first time
your program blows up because you have cross-mounted volumes, it’s the
logical thing to add - “have I seen this volume before, if so, don’t
traverse it.”)
Tony
OSR
On Wed, Nov 4, 2009 at 5:16 PM, Tony Mason wrote:
> What?s fun is when you traverse mount points. The root directory of the
> new volume won?t show ?.? or ?..? entries. Thus, this becomes a simple
> technique for noticing when you?ve walked across a mount point. I wouldn?t
> be surprised to find out someone else has noticed this and used this
> characteristic to detect them, since checking every directory to see if it
> is a mount point would be rather expensive (and the first time your program
> blows up because you have cross-mounted volumes, it?s the logical thing to
> add ? ?have I seen this volume before, if so, don?t traverse it.?)
>
That’s a good find. I’m glad IoManager doesn’t try to fake up “.”, “…” for
mountpoints–that could get really messy if the FSD also wanted to generate
them too, and they conflicted. Also the fact that those mountpoints do omit
., … is good de facto proof that having the FSD list or parse them is not
required, I think.
Interesting technique too. You’d probably want to also have a case to
recognize UNIXy filesystems that would generate “…” pointing to “.” in the
root directory, to prevent seeing “…” and assuming it wasn’t in a
mountpoint.
Jeff Rhyason
El Fresko Technologies
Jeff Rhyason wrote:
On Wed, Nov 4, 2009 at 5:16 PM, Tony Mason > mailto:xxxxx> wrote:
>
> What’s fun is when you traverse mount points. The root directory of
> the new volume won’t show “.” or “…” entries. Thus, this becomes a
> simple technique for noticing when you’ve walked across a mount
> point. I wouldn’t be surprised to find out someone else has noticed
> this and used this characteristic to detect them, since checking
> every directory to see if it is a mount point would be rather
> expensive (and the first time your program blows up because you have
> cross-mounted volumes, it’s the logical thing to add – “have I seen
> this volume before, if so, don’t traverse it.”)
>
> That’s a good find. I’m glad IoManager doesn’t try to fake up “.”, “…”
> for mountpoints–that could get really messy if the FSD also wanted to
> generate them too, and they conflicted. Also the fact that those
> mountpoints do omit ., … is good de facto proof that having the FSD
> list or parse them is not required, I think.
>
Well, for some redirectors I have worked on they do support symlinks
which can be relative, that is containing a . or a … embedded within a
path, not at the start of a path. In these cases the file system needs
to deal with them as well as fun things like relative symlinks which end
up walking backwards through the root of a volume.
Pete
> Interesting technique too. You’d probably want to also have a case to
> recognize UNIXy filesystems that would generate “…” pointing to “.” in
> the root directory, to prevent seeing “…” and assuming it wasn’t in a
> mountpoint.
>
> Jeff Rhyason
> El Fresko Technologies
>
> — NTFSD is sponsored by OSR For our schedule of debugging and file
> system seminars (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars To unsubscribe, visit the List Server
> section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295</mailto:xxxxx>
Pete, I’m assuming those redirectors in question were handling the …
references internally. That’s one reason the namei code in UNIX was
often so hairy - relative symbolic links that crossed mount points
worked, but they were handled by the OS name resolution code.
Of course, as we’ve learned, the symlink implementation on Windows is
subtly different than it is on UNIX platforms.
The “.” and “…” trick I described would only work on Windows file
systems (hmm, that makes me wonder if you use the NFS server in S08 and
the NFS client in Vista/Win7 do you see the Windows/NTFS semantics for .
and … or do you see the UNIX semantics? Ah, the fun of it all.)
Tony
OSR
Tony Mason wrote:
Pete, I’m assuming those redirectors in question were handling the …
references internally. That’s one reason the namei code in UNIX was
often so hairy - relative symbolic links that crossed mount points
worked, but they were handled by the OS name resolution code.
Yes, they handled the . and … internally and managed the crossing of
mount points in both directions due to these semantics. Yes, hairy to
say the least!
Pete
Of course, as we’ve learned, the symlink implementation on Windows is
subtly different than it is on UNIX platforms.The “.” and “…” trick I described would only work on Windows file
systems (hmm, that makes me wonder if you use the NFS server in S08 and
the NFS client in Vista/Win7 do you see the Windows/NTFS semantics for .
and … or do you see the UNIX semantics? Ah, the fun of it all.)Tony
OSR
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295