On 2002.01.14 13:21 Francois Gouget wrote:
On Mon, 14 Jan 2002, Ove Kaaven wrote:
On Sun, 13 Jan 2002 ccrayne@crayne.org wrote:
Change Log: files/dos_fs.c ccrayne@crayne.org Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*."
instead
of as "*.*"
This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff
that
used to confuse DOS users converting to Linux - "*.*" no longer meant
all
files...)
Strange because if I open a 'dos box' in Win95 or NT4, and I type 'dir *' I get a list of all the files, including those that have an extension like "autoexec.bat".
Yup! With long filenames windows treats the extension like UNIX does. That is a "dir *" will in fact show all files in the directory when command.com is running under windows.
When it's not running under windows a "dir *" is equivilent to a "dir *."
As for dir *.* showing filenames not containing a dot... well, I think this is because short names are still around and therefore when you look up the file as an 8.3 name *.* does match it because a file named "FOOBAR" will have the shortname equivilant to "FOOBAR."
Anybody know what happens under NT if you turn off short name generation, then make a file named foobar and then do a dir *.* in that directory? I am guessing MS has this figured out and when the windows APIs see "*.*" they convert it to a simple "*". Of course I could be wrong and it may in fact simply not show the file since *.* would not match it by standard wildcard rules as it has no shortname with an implicit dot and the longname doesn't contain a dot.
Should be simple enough to test. Load up NT or 2k, mod the reg to disable short filenames, reboot, make the file then do a dir /x (I think it is /x) to show both long and short filenames and verify it does not have a SFN. Then dir *.* and see if it finds it.
-Dave