|
|
Dir /X at least shows you why
I have three files in this test directory:
test.htm
test2.html
test3.htmasdflkjasdgf
If you do a dir /X (show short names of files) it lists the short names and you can see that the extension only uses first 3.
C:\Users\ns\test>dir *.htm /X
Volume in drive C has no label.
Volume Serial Number is 509B-CBCC
Directory of C:\Users\ns\test
12/04/2014 11:31 AM 9 test.htm
12/04/2014 11:32 AM 11 TEST2~1.HTM test2.html
12/04/2014 11:32 AM 11 TEST3~1.HTM test3.htmasdflkjasdgf
3 File(s) 31 bytes
However, I think it is stupid and annoying also.
ls *.htm works perfectly.
|
|
|
|
|
|
it is a "feature" so you find all your Excel files
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
But I can say dir *.xls* to do that when, and only when, I want to.
|
|
|
|
|
How do you know what you want to see? Only Microsoft knows what you want. Duh.
|
|
|
|
|
When I want to see what Microsoft thinks I want to see I use Bing Videos.
|
|
|
|
|
|
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.
|
|
|
|