|
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!
|
|
|
|
|
We have partnered with Google Helpouts to provide an additional way for you to interact with those looking to get answers to programming questions. For those unfamiliar with Helpouts it allows people to connect via chat, voice, video and screen-sharing. Using Helpouts to connect a person with a question with an expert who can help means there can be a faster back-and-forth conversation, the code can be seen, and suggestions can be tried and follow up suggestions made if needed.
At this point it's available for C++, C# and ASP.NET topics in the forums and Quick Answers. It's also restricted to those asking questions from the U.S., Australia, New Zealand, India, Brazil, Indonesia, Russia, Philippines, and Japan. Only U.S. members can, at this point, signup to become Helpouts experts.
A brief overview can be found here[^].
Browser support is limited to current and prior major releases of major browsers, ie
We support current and prior major release of Chrome, Firefox, Internet Explorer and Safari on a rolling basis, this is the same support for browsers across all Google Apps.
• IE 10+
• FireFox 31+
• Safari 5 and 6
• Chrome 31 (any version using Webkit 536)
cheers
Chris Maunder
|
|
|
|
|
Orion's lunch postponed for 24 hours at least...
http://www.nasa.gov/[^]
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Why? I don't understand, weather looks good and omg i just saw it -.-
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Some fuel-valve problem...
But it was canceled in the last 2 hours 3 time because of wind...21 knot[^] maximum permitted...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Okay, have no sound.
Well yes it actually did look quite windy there.
but it's sad 
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
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.
