in reply to Re^5: readdir() on a sysopen() handle?
in thread readdir() on a sysopen() handle?

. and .. is not returned for the root of some drives on Windows.

I would have betted against that statement. But it seems Windows is that crazy.

#!/usr/bin/perl use v5.12; use warnings; sub readroot { my $drive=shift; my $name="$drive:/"; if (opendir my $d,$name) { my @list=grep /^\.{1,2}$/, readdir $d; closedir $d; return join(' ',"$drive:",@list); } return "$drive: $!"; } say readroot($_) for ('A' .. 'Z');
X:\>subst E:\: => C:\windows F:\: => C:\ X:\>perl readdir.pl A: No such file or directory B: Invalid argument C: D: E: . .. F: G: No such file or directory H: . .. I: . .. J: No such file or directory K: No such file or directory L: No such file or directory M: . .. N: No such file or directory O: No such file or directory P: No such file or directory Q: No such file or directory R: . .. S: No such file or directory T: . .. U: V: . .. W: No such file or directory X: Y: No such file or directory Z: Invalid argument X:\>

Drive classification:

Looking at the result, it seems that the real root directories of at least NTFS and FAT on Windows don't have the . and .. directory entries (C:, D:, F:, U:, X:), and that is also visible through SUBST and network sharing. Other directories do have the . and .. directories (E:, V:), and this is also visible through SUBST and network sharing. Samba does not try to fake root directories - at least not for the non-root directories shared by my Linux server, and so the Samba shares also have the dot directories (H:, I:, M:, R:, T:).

(All tested on Windows 7)

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)