|
|
That's odd. It doesn't do that for me on Win 8.1.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Users\jeremy.falcon>cd C:\windows
C:\Windows>dir *.lo
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of C:\Windows
File Not Found
C:\Windows>dir *.log
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of C:\Windows
03/17/2014 09:02 PM 2,664 DtcInstall.log
11/18/2014 09:03 AM 613,588 PFRO.log
11/18/2014 09:31 AM 3,405 setupact.log
09/24/2014 08:29 AM 0 setuperr.log
09/29/2013 10:20 PM 5,446 vmgcoinstall.log
12/03/2014 08:24 PM 1,947,077 WindowsUpdate.log
6 File(s) 2,572,180 bytes
0 Dir(s) 386,710,196,224 bytes free
C:\Windows>
Jeremy Falcon
|
|
|
|
|
Create a file with an extension like logger, or login, or something and try it. (I don't have 8.x handy.)
|
|
|
|
|
Well that's messed up. Apparently 3 is the magic number for extensions to cause the screw up. Check this out...
c:\>dir *.*
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of c:\
11/25/2014 02:35 PM <DIR> Code
12/04/2014 11:09 AM 0 cp.logger
08/22/2013 09:22 AM <DIR> PerfLogs
11/18/2014 09:48 AM <DIR> Program Files
12/03/2014 09:44 AM <DIR> Program Files (x86)
03/18/2014 07:59 AM <DIR> Users
11/18/2014 09:59 AM <DIR> Windows
1 File(s) 0 bytes
6 Dir(s) 386,709,864,448 bytes free
c:\>dir *.lo
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of c:\
File Not Found
c:\>dir *.log
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of c:\
12/04/2014 11:09 AM 0 cp.logger
1 File(s) 0 bytes
0 Dir(s) 386,709,864,448 bytes free
c:\>ren cp.logger cp.lo
c:\>dir *.lo
Volume in drive C has no label.
Volume Serial Number is 0000-0000
Directory of c:\
12/04/2014 11:09 AM 0 cp.lo
1 File(s) 0 bytes
0 Dir(s) 386,709,839,872 bytes free
c:\>
Jeremy Falcon
|
|
|
|
|
'Xac'ly, pull up a stool.
|
|
|
|
|
It does the same with htm and html files. I suspect it's only dealing with three significant characters for the extension.
|
|
|
|
|
Sigh. All of this arises from the FindFirstFile()[^] Windows API function, which matches both long and short filenames, when the underlying file system supports both. This is the case for NTFS, although you can turn short filename generation off.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: you can turn short filename generation off
Sounds good. How?
modified 4-Dec-14 13:21pm.
|
|
|
|
|
|
|
This is one of the things we did at my previous job when we shipped (surveillance) DVRs. Windows Explorer becomes incredibly slow when you have millions of files on a drive.
I have never seen a problem related to this setting.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
On Win7 the default is 2, so I disabled and stripped short names on my work volume. I'll do the same at home.
|
|
|
|
|
Sounds like a backwards-compatibility issue:
But some quirks of the FCB matching algorithm persist into Win32 because they have become idiom.
For example, if your pattern ends in .*, the .* is ignored. Without this rule, the pattern *.* would match only files that contained a dot, which would break probably 90% of all the batch files on the planet, as well as everybody's muscle memory, since everybody running Windows NT 3.1 grew up in a world where *.* meant all files.
As another example, a pattern that ends in a dot doesn't actually match files which end in a dot; it matches files with no extension. And a question mark can match zero characters if it comes immediately before a dot.
There may be other weird Win32 pattern matching quirks, but those are the two that come to mind right away, and they both exist to maintain batch file compatibility with the old 8.3 file pattern matching algorithm.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: everybody running Windows NT 3.1 grew up in a world where *.* meant
all files.
Ah, but I cut my teeth in VMS, where *.* does mean there must be a dot (as there always is in VMS anyway) and that's what I expect of an enterprise-quality Operating System. VMS also allows ... to indicate "any subdirectory", which is a more powerful/flexible version of recursion because you don't have to put it at the end [...DATA]*.* isn't just any file, it's only the ones in a DATA directory.
At least wildcard matching has been improved in recent versions of DOS -- it used to be that literal characters after wildcards were ignored, so DIR APP*DAT.* would ignore the DAT part. 
|
|
|
|
|
PIEBALDconsult wrote: Ah, but I cut my teeth in VMS, where *.* does mean there must be a dot
That's the way it should be IMO. Unfortunately DOS used the concept of extensions very, very heavily since its inception though. So a file wasn't considered a "real" file until it had one. As such, *.* became the thing for all things when searching since there just were no files without an extension.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: no files without an extension
Exactly, every file has an extension; it may be an empty extension. In VMS, directories have an extension of DIR.
|
|
|
|
|
Really? I'm the opposite with that. I like the way Macs and Unix/Linux does it. They use the files MIME type or some magic metadata type rather than base it on an extension. blah.txt could very well be an image on a Mac, whereas on Windows (VMS too??) it may be an image file but with that name it's gonna have a text file icon on it.
Oh, I will say though, that some things in Linux use the extension nowadays. Like ls colors. So, was interesting while it lasted I suppose.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: rather than base it on an extension
No, the extension doesn't have any real/functional meaning, but for a directory it has to be DIR. A directory is a directory, not just any file with a DIR extension.
Aside for most executables (EXE most commonly), I don't think I've encountered extensions that have any actual meaning on any system.
You'll be aware of the Executable attribute in *nix.
Speaking of executables, in Windows you can make your own "executables" by adding the extension to the PATHEXT Environment Variable and setting the file association appropriately.
Jeremy Falcon wrote: it's gonna have a text file icon on it.
I disabled that.  That's only file association anyway, you can change the icon easily, the OS don't care.
In DOS (and *nix?), there is basically ony one "type" of file -- a sequence of bytes -- which, at best, can be categorized as either "binary" or "text", but the OS makes no actual distinction. The OpenVMS Record Management System has many attributes for files, and even a "text" file may use CRLF, LF, or CR for newline, it may have Fortran control characters, it could have fixed-size records. The OS knows these things and can act appropriately.
modified 4-Dec-14 16:20pm.
|
|
|
|
|
PIEBALDconsult wrote: In DOS (and *nix?), there is basically ony one "type" of file -- a sequence of bytes -- which, at best, can be categorized as either "binary" or "text", but the OS makes no actual distinction.
That's right. However, some if its desktop environments don't. Although I'm crusty with the desktops on *nix since I use it as a server, for all I know that may have changed by now.
PIEBALDconsult wrote: The OpenVMS Record Management System has many attributes for files, and even a "text" file may use CRLF, LF, or CR for newline, it may have Fortran control characters, it could have fixed-size records. The OS knows these things and can act appropriately.
That's cool. The geek in me wants to check it out. The old guy in me is saving brain space though, for booze.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: The old guy in me is saving brain space though, for booze.
Yes, no reason to go out and learn it now, it won't be The Next Big Thing.
|
|
|
|
|
Another alternative: use Everything[^]. When there is a "*" in the string (if the option is set), it will find exact matches. So a "*.xls" or a "*xls" will both match items with 'xls' in it without a trailing 'x'. Of course, the first will give you only extensions. And it is freaking fast.
|
|
|
|
|
I've been using the DIR and the command line on several Operating Systems for thirty years, I ain't gonna change now.
|
|
|
|
|
I've used 'dir' many, many times myself. Everything is still a handy tool worth being aware of.
|
|
|
|
|
David O'Neil wrote: Everything is still a handy tool worth being aware of.
Well, yes, but it decreases my personal bliss. 
Seriously, I'll give Everything a further look later, but I'm unlikely to use it. I may have reason to pass the word on though.
|
|
|
|
|
It's all about bliss! Everything increased mine, because it made remembering paths pretty much unnecessary. With 666,201 'objects' on my C drive (according to Everything), even with Libraries, finding stuff was not very fun. But now I just type in the file name and quickly narrow stuff down for the items my memory gives me problems with. (Which is stuff that logically can be in several libraries - I don't take libraries that far!) Huge time saver over 'dir' and the other approaches I tried.
Have fun, whichever method you use!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Not sure I'll do it, but I'm reading up on it.