So THAT's how you get a file extension
-
-
I didn't try it out but at least he's checking for the final dot in the pathname. The first comment is completely wrong. Obviously it should have been:
String fn = "myFilename.extradothere.myExtension";
String[]] fns = fn.Split('.');
String ext = fns[fns.Length - 1];Seriously:
String ext = System.IO.Path.GetExtension("myFilename.extradothere.myExtension");
-
Obviously, depending on your language of choice:
return inputstring.split('.').pop();
TRWTF of course being that extensions are considered important - they're just an indication at best.
-
@Monomelodies said:
TRWTF of course being that extensions are considered important - they're just an indication at best.
I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.
-
@DrJokepu said:
@Monomelodies said:
TRWTF of course being that extensions are considered important - they're just an indication at best.
I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.They're meant to be important, sure. But since the user can change them to whatever he wants at any time, they cannot be trusted to always provide an accurate indication of what a file actually is.
-
@DrJokepu said:
@Monomelodies said:
TRWTF of course being that extensions are considered important - they're just an indication at best.
I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.Yeah, and that's TRWTF...
-
@hvm said:
Yeah, and that's TRWTF...
QED :) My favourite part is that they're supposed to be important, but Windows hides them by default. C'mon...
-
-
@Monomelodies said:
QED
Quod erat demonstrandum is used at the end of mathematical proofs as an indication that the proof is finished, usually as a placeholder so that you can skip to the end of the proof quickly and continue reading whatever paper in which the proof is contained. It means "Which was meant to be shown", though I'm sure your favourite Wikipedia has another translation of it which amounts to the same thing but you will try to use against me somehow.What you did was state "The real WTF is extensions are important". Then hvm said "The real WTF is extensions are important", which isn't a proof of your statement. It's simply a restating of it without any logical backing. Then you said QED, indicating that your original statement was proven, when it in fact has not been. If you think one could prove statements by restating them, then I have some rocks I want to sell you. They keep bears away: they keep bears away. QED
-
@Monomelodies said:
QED :)
Huh? Quod erat demonstrandum? That doesn't make any sense in this context
@Monomelodies said:My favourite part is that they're supposed to be important, but Windows hides them by default.
Windows displays icons, which are (partially) based on the extension. The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension. The technical decision to have extensions in CP/M was made decades ago and it might or might not be relevant today. Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.
-
@Welbog & DrJokepu
But you see, someone agreed with him! If two people agree on something, it must be true. That's how we know that Windows sucks. Also, Linux sucks, BSD sucks, AIX sucks, Solaris sucks. Two people agree on it it must be true!
-
@TooWhiteAndNerdy said:
That's how we know that Windows sucks. Also, Linux sucks, BSD sucks, AIX sucks, Solaris sucks. Two people agree on it it must be true!
Thank God I use the only operating system that everyone can agree doesn't suck: MINIX.
-
@DrJokepu said:
Windows displays icons, which are (partially) based on the extension. The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension. The technical decision to have extensions in CP/M was made decades ago and it might or might not be relevant today. Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.
Exactly. It made sense at one time and even if it is a bit cumbersome today, it's not that big of a deal. MIME is maybe a tad better, but the UNIX "magic number" method is absolutely the stupidest thing ever. How anyone can bitch about Windows file extensions while using Linux is beyond me. Mac OSX probably has the best way of representing the data with the Uniform Type identifiers, which are basically like MIME types, except they are oriented around the concept of who produced the file format and not an arbitrary spec that may vary between apps.
-
@bstorer said:
@Monomelodies said:
QED
I don't think that means what you think it means.I am so sorry for confusing you all. No, really. My apologies. I'll try to be clearer next time, right? We all friends again now? I was of course referring to the excellent post I was quoting highlighting the "at least, they are meant to be" part, which is the QED in this whole story. Again, sorry for assuming you'd get that.
-
@DrJokepu said:
Windows displays icons, which are (partially) based on the extension.
Windows displays icons? Cool! I gotta try it someday...</sarcasm>
@DrJokepu said:
The action triggered by doubleclicking on the icon, the contents of the context menu, and the million ways the shell interacts with a file all depend on the extension.
Yeah, and that's the part that scares me. When designing a system I surely wouldn't let anything depend on a parameter so easily edited. (And I definitely wouldn't hide it by default!)
@DrJokepu said:
Personally, I think it provides a simple way to store basic metadata about a file: the type. It certainly made sense 20-30 years ago, when the available resources of computers were of much less extent.
It makes sense in that in most cases, it'll be correct and then it's a quick and human-readable way to determine the file-type. But that's something totally different than saying it's in any way relevant - is a binary containing a program less a program if I change the extension from .exe to .fyf? I don't think so. I sure as hell wouldn't depend on it when dealing with files...
-
@morbiuswilters said:
but the UNIX "magic number" method is absolutely the stupidest thing ever
Correct me if I'm wrong (no, really!) but wasn't that originally some (agreedly, shitty) way of dealing with memory management? The idea of magic numbers identifying file types is wide-spread nowadays (e.g., in every standardised image format I can think of) and if nothing else is certainly not arbitrary between apps - that's why file formats are defined (a PNG made in Gimpon Linux will work in Photoshop on Windows because, like, the PNG format is standardised, and the first bytes signal that it should at least in theory be a valid PNG file).
But maybe I misunderstood you?
@morbiuswilters said:
except they are oriented around the concept of who produced the file format and not an arbitrary spec that may vary between apps.
I can see that coming in handy:
if (file.type == 'html') {
if (type.generator.match(/m(icro)?s(oft)?/)) {
parse(file.contents, PARSER_QUIRKS_MODE);
} else {
parse(file.contents, PARSER_COMPLIANT_MODE);
}
}... or something to that extent...
(yes, I was being sarcastic there - it feels like a solution to a problem that shouldn't be there in the first place. But I don't know OSX well enough to determine if this is a good idea that works well in practice, a bad idea that works anyway, or simply not true.)
-
@morbiuswilters said:
How anyone can bitch about Windows file extensions while using Linux is beyond me.
The one thing I hate about UNIX based filesystems is case sensitivity. It really pisses me off when teSt.txt is considered different from test.txt, and both can exist in the same directory! I can tolerate case sensitivity in a programming language, but it's ridiculous when imposed on files!
-
@donniel said:
The one thing I hate about UNIX based filesystems is case sensitivity. It really pisses me off when teSt.txt is considered different from test.txt, and both can exist in the same directory! I can tolerate case sensitivity in a programming language, but it's ridiculous when imposed on files!
I think the opposite. I don't think Windows should treat the two filenames as the same. It just "feels" more right to have the filesystem be case sensitive. However, I can't think of a real-life example of where it fucked me over on either OS.What does get me sometimes is the difference between how Windows Explorer treats numbers versus UNIX's ls.
If you have file1.txt, file2,txt, all the way to file100.txt, ls will sort them alphabetically, with 10 coming between 1 and 11. Windows Explorer will order them by the number, basically assuming a preceding 00 or 0.
The "solution*" is simple. I always zero pad numbers in file names. That way they're ordered the same in Windows Explorer and ls.
*solution to a problem that's probably only in my head, and I've never heard anyone else complain about.
-
@Monomelodies said:
It makes sense in that in most cases, it'll be correct and then it's a quick and human-readable way to determine the file-type. But that's something totally different than saying it's in any way relevant - is a binary containing a program less a program if I change the extension from .exe to .fyf? I don't think so. I sure as hell wouldn't depend on it when dealing with files...
Well if windows won't run the program if it has the extension .fyf, program.fyf is not a functional program. The extension IS important in windows. Saying it's not important is the same as saying that the executable bit in a UNIX permission is not important.
-
@Monomelodies said:
Yeah, and that's the part that scares me. When designing a system I surely wouldn't let anything depend on a parameter so easily edited. (And I definitely wouldn't hide it by default!)
...
I sure as hell wouldn't depend on it when dealing with files...
I don't see what the security risk of filename extensions is, or why it's scary...in fact, it's an easy way to see what's going to happen when you open the file. Sure, you can take a virus and rename it with a .gif extension or something, and no one will suspect it's a virus, but when you try to open it, it won't be run since Windows treats it as an image. You can't run a program without knowing it, since it's easy to see the .exe on the end, even if you change the program icon to make it look like another file type. That's why I always laugh at the viruses I get by e-mail, which say "open this amazing image!", and then have an attachment named baseball.jpg.exe or something like that.
Now with extensions hidden of course, you can do just that and it'll be much harder to see that the supposed image you downloaded is really a program until you try to open it, but as long as you keep the extensions visible then it's fine.
Also, for depending on the extension to deal with files, just about all programs create files with the right extension anyways, so if they don't you can assume that someone changed it for a reason (trying to open an image in Notepad, for example, by renaming with a .txt extension).
@morbiuswilters said:
the UNIX "magic number" method is absolutely the stupidest thing ever
Not the perfect solution, of course, but it's a bit better (for accuracy) than file extensions if it's used right. ELF programs, PNGs, JPEGs, and bitmaps all have a certain string near the beginning of the file which is part of the standard - it's not a PNG if it doesn't have the "PNG" in it - so it's a 99% foolproof way to detect these file types (the 1% is for if you have a binary file for something completely different which just happens to have the exact same sequence). Plenty of other file types have these identifying strings (or just a few "magic" bytes) too, so it's pretty accurate. Now if some people had decided way back that the first X bytes of every file would be the MIME type as text, then that would make things easier, but the "magic number" detection seems to me like a pretty good substitute.
Now, a bad use for the whole "matching patterns in file contents" thing is with types of text files. GNOME comes with a MIME type for C source files based on contents, and it's always detecting my assembly sources (which have #include on the first line) as C source files and bringing up the "this file is different than it appears" security dialog and refusing to open them by a simple double-click, which is a huge pain in the ass.
-
@TooWhiteAndNerdy said:
If you have file1.txt, file2,txt, all the way to file100.txt, ls will sort them alphabetically, with 10 coming between 1 and 11. Windows Explorer will order them by the number, basically assuming a preceding 00 or 0.
Windows Explorer using natural sorting instead of strict alphabetical sorting for filenames is actually a feature. Most users expect a natural order since they don't give a shit about how computers work. Most users are not programmers.
-
@TooWhiteAndNerdy said:
@donniel said:
The one thing I hate about UNIX based filesystems is case sensitivity. It really pisses me off when teSt.txt is considered different from test.txt, and both can exist in the same directory! I can tolerate case sensitivity in a programming language, but it's ridiculous when imposed on files!
I think the opposite. I don't think Windows should treat the two filenames as the same. It just "feels" more right to have the filesystem be case sensitive. However, I can't think of a real-life example of where it fucked me over on either OS.WIndows supports case-sensitivity. See CreateFile/FILE_FLAG_POSIX_SEMANTICS. But the sad thing is that even if you make your program to use that, 99.99% of other programs won't be able to open files based on the name case, because they don't pass this flag to CreateFile.
@TooWhiteAndNerdy said:
If you have file1.txt, file2,txt, all the way to file100.txt, ls will sort them alphabetically, with 10 coming between 1 and 11. Windows Explorer will order them by the number, basically assuming a preceding 00 or 0
That's the case from Windows XP. And that makes more sense than ASCII order sort. By the way, ls doesn't sort them "alphabetically", it's ASCII order. Alphabetical sort takes into account language sort rules, with all those umlauts and what else.
-
@DrJokepu said:
@Monomelodies said:
TRWTF of course being that extensions are considered important - they're just an indication at best.
I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.Extensions go back to the Dark Ages. They certainly existed on TOPS-10 in the 1970s. Probably well before that, but that's the limit that I can personally attest to.
-
@alegr said:
WIndows supports case-sensitivity.
Not by default - you need to turn it on in Registry. And it has some funny side-effects.
-
@burntfuse said:
I don't see what the security risk of filename extensions is, or why it's scary...
Only if you assume every program you ever use adheres to it. And that's a pretty scary assumption to make, IMNSHO.
Remember, I'm not saying extensions per se are bad - on the contrary, they're a great human-readable way to quickly assess the file type. You just shouldn't trust them blindly, and that's what DOS/Windows seems to do. They don't MEAN anything - they're an indicator, nothing more, nothing less.
-
@SuperousOxide said:
Well if windows won't run the program if it has the extension .fyf, program.fyf is not a functional program. The extension IS important in windows. Saying it's not important is the same as saying that the executable bit in a UNIX permission is not important.
The key is that the executable bit is not something that gets transferred in a download or whatever - it requires human interaction. The extension OTOH is always preserved. I wonder, what is more secure?
Having said that, you make a sort-of valid point: computers need some sort of flag to signal that something is executable. I'll grant you that. I uphold however that the better way is to grant these permissions manually on a per-file basis, not on a per-extension-that-every-jack-might-execute-accidentally basis.
I'm not saying it's perfect. I'm just saying it's way better than using that sodding extension any script-kiddy might have changed.
-
So I guess the question we really need to ask is: how does LINDOWS deal with extensions?
-
@matterific said:
http://www.developerfusion.co.uk/show/6332/
Or not
This resource has not currently been approved, and is not currently linked to from our directory of resources. It is being displayed here for preview by the author and moderators only.
So which are you then? A moderator - or was it YOU who wrote it in the first place?
Confess, sinner!
-
@Monomelodies said:
The key is that the executable bit is not something that gets transferred in a download or whatever - it requires human interaction.
Note that NT has Executable permission, too, and while by default all files get it, strange things happen when it's not set (eg. when you manipulate files from cygwin). With .exe files, you'll just get a Permission denied error when you try to run them, but if you remove the Executable ACL from DLL files, programs will fail in more misterious ways.@Monomelodies said:I wonder, what is more secure?
The Unix way, because you have to consciously mark the file as executable before you're able to run it? (the executable bit should have no effect on graphical file managers when you're dealing with non-executable files)
-
@Monomelodies said:
I'm not saying extensions per se are bad - on the contrary, they're a great human-readable way to quickly assess the file type. You just shouldn't trust them blindly, and that's what DOS/Windows seems to do. They don't MEAN anything - they're an indicator, nothing more, nothing less.
That is completely retarded. You might as well be saying that you shouldn't trust the BOM in Unicode, or the doctype in HTML, or the packet flags in a networking app, because they are merely "indicators", and you always need to perform deep inspection to be sure.
Think about what you're saying. Sure, you might be able to identify a PNG with 99% certainty based on the header, but that assumes you've already guessed what's in the file. This is never the case. Instead, the shell would have to cycle through every single registered file type on the system until it finds a match. How can it be certain it's a match? Well, it can't, really. And try to imagine doing this on a folder with 5000 log files in order to determine what icons to display. Even if you used the file extension as a guideline, if it doesn't match (this will happen even under normal operation - think NFO), then you're back to square one and have to perform the same idiocy.
And we haven't even considered the case of proprietary file types. How the hell would the XP shell recognize, say, a Word 2007 XML document, when the format wasn't even conceived until years after XP came out? Is every application supposed to register some sort of "validator" that determines whether or not it created any given document, and if so, isn't that a gaping security hole? Or are you advocating the old Mac style where the type was stored in a resource fork, which was hidden from users but still very much mutable, making it essentially the same thing as the Windows version with the "hide file extensions" option turned on?
I also have to assume that you're referring specifically to the Shell API in Windows (or more specifically Explorer), because the operating system itself doesn't care a lick about file extensions. What any individual program does with a file extension, or even the contents of that file, is up to the program. There's no conceivable way for the OS to enforce any kind of specific logic.
Finally - what, precisely, is "scary" about the shell trusting file extensions? What is the worst possible thing that could happen if a file has the wrong extension? It will fail to open in the target program. Wow, I'm frightened. I want my mommy!
Please, go back to /.
-
@Monomelodies said:
I uphold however that the better way is to grant these permissions manually on a per-file basis, not on a per-extension-that-every-jack-might-execute-accidentally basis.
Aside from being a massive inconvenience to 99% of computer users, it doesn't even really accomplish anything. It would be a pretty nutty coincidence if a data file, accidentally executed, would run long enough to actually do any damage.
You can "uphold" whatever you want, but I've never heard of any credible experts in the security field whining about file extensions.
-
@Aaron said:
And try to imagine doing this on a folder with 5000 log files in order to determine what icons to display.
A certain popluar toolkit already does this (hint: don't ever try to browse to /usr/bin with GTK+ filechooser).
-
@alegr said:
By the way, ls doesn't sort them "alphabetically", it's ASCII order. Alphabetical sort takes into account language sort rules, with all those umlauts and what else.
Have you ever used unix-like systems with the non-default locale? Of course ls filename sorting is based on the strcoll() family of functions and sorts like defined in the locale, you can set the locale via the environment variables LC_ALL or LANG or just the collation order via LC_COLLATE (which Gnome etc. set on login for you).
-
@Monomelodies said:
Except that if you recieve your file in an archive (hardly unusual), the execute bit is (almost always) preserved...The key is that the executable bit is not something that gets transferred in a download or whatever - it requires human interaction. The extension OTOH is always preserved. I wonder, what is more secure?
-
@ender said:
@Monomelodies said:
The key is that the executable bit is not something that gets transferred in a download or whatever - it requires human interaction.
Note that NT has Executable permission, too, and while by default all files get it, strange things happen when it's not set (eg. when you manipulate files from cygwin). With .exe files, you'll just get a Permission denied error when you try to run them, but if you remove the Executable ACL from DLL files, programs will fail in more misterious ways.@Monomelodies said:I wonder, what is more secure?
The Unix way, because you have to consciously mark the file as executable before you're able to run it? (the executable bit should have no effect on graphical file managers when you're dealing with non-executable files)FILE_EXECUTE access right gives a permission to pass the handle to CreateFileMapping and map in with PAGE_EXECUTE_READ, which means the file can be mapped to memory, for example as an executable EXE or DLL image. Thus, without that permission, an EXE file won't start at all. Note that GENERIC_READ doesn't require that access right. Now, if a DLL can't be opened with FILE_EXECUTE access, LoadLibrary will fail, and not every application handles that error.
-
@Aaron said:
I also have to assume that you're referring specifically to the Shell API in Windows (or more specifically Explorer), because the operating system itself doesn't care a lick about file extensions
There is a special case in CreateProcess, if it gets .CMD file. That will start CMD.EXE with that file as an argument.
-
@Aaron said:
@Monomelodies said:
I'm not saying extensions per se are bad - on the contrary, they're a great human-readable way to quickly assess the file type. You just shouldn't trust them blindly, and that's what DOS/Windows seems to do. They don't MEAN anything - they're an indicator, nothing more, nothing less.
That is completely retarded. You might as well be saying that you shouldn't trust the BOM in Unicode, or the doctype in HTML, or the packet flags in a networking app, because they are merely "indicators", and you always need to perform deep inspection to be sure.
Unfortunately, Windows is both inconsistent and retarded*. Sometimes it treats the extensions as gospel; other times it ends up sniffing the file format (aka 'deep inspection') and parsing it as what it thinks it is.
@Aaron said:
Finally - what, precisely, is "scary" about the shell trusting file extensions? What is the worst possible thing that could happen if a file has the wrong extension? It will fail to open in the target program. Wow, I'm frightened. I want my mommy!
Well, actually the worst possible thing that could happen is that it might succeed to open in the target program - but then behave differently than expected owing to being capable of carrying unexpected (e.g., rich or active) content types.
* - Gotta give 'em points for completeness, though ;-)
-
@DaveK said:
Unfortunately, Windows is both inconsistent and retarded*. Sometimes it treats the extensions as gospel; other times it ends up sniffing the file format (aka 'deep inspection') and parsing it as what it thinks it is.
Examples?
@DaveK said:
Well, actually the worst possible thing that could happen is that it might succeed to open in the target program - but then behave differently than expected owing to being capable of carrying unexpected (e.g., rich or active) content types.
You're now talking about an instance where the same program opens both file types. So think about it - even if the Shell API inspected the file byte by byte, it would come to the conclusion that it's a different file type, and open it with the exact same program. This "vulnerability" has nothing whatsoever to do with the OS.
It's up to Media Player or Winamp to take a look at the file it's trying to open and perhaps display a warning to the effect of "This file is labelled as an .MP3 (Audio File) but actually appears to be a .WMV (Video File). Do you still want to try opening it?" Some programs actually do this (IIRC, IrfanView complains when you open an image with an inconsistent extension).
That's the responsibility of individual vendors though, not the OS.
-
@Aaron said:
Examples?
Font files. Even when most of them have extension .ttf, Explorer will examine them more deeply to see if they're OpenType instead of TrueType, and if they are, give them a different icon.
-
@DaveK said:
Unfortunately, Windows is both inconsistent and retarded*. Sometimes it treats the extensions as gospel; other times it ends up sniffing the file format (aka 'deep inspection') and parsing it as what it thinks it is.
Linux* doesn't use only magic numbers either. docx and zip files are handled differently on my computer, both in Linux and in Windows. If Linux used only magic numbers, it wouldn't be able to tell the difference between docx and zip and would not be able to have them open in different applications.
* Linux is really just the kernel and it is the file manager which stores open with settings using file extensions
-
@DaveK said:
@matterific said:
http://www.developerfusion.co.uk/show/6332/
Or not
This resource has not currently been approved, and is not currently linked to from our directory of resources. It is being displayed here for preview by the author and moderators only.
So which are you then? A moderator - or was it YOU who wrote it in the first place?
Confess, sinner!
Yeah I wrote it. That's what I do, I write shit code examples, wait a few months then post it to TDWTF.
-
@Aaron said:
Examples?
Shell extension handlers. (Which are responsible for what DaveK sees, though he doesn't know the name or where to find them.)An easy one to show is metadata handlers. If you open a folder which has a bunch of MP3's in it, you'll notice that the Artist, Title, Length, et cetera columns autopopulate. [i][edit]For some other reason.[/edit][/i] This is because Windows saw that files with extension .MP3 have custom column handlers in the registry, under HKCR/.mp3/PersistentHandler. You'll also find some living under HKCR/.mp3/shellex; these are for context menu dropdowns so Windows Media Discombobumalator can diddle with the list.
You'll also see this with Visual Studio solution files. VS installs a shell icon handler that checks the version of the solution and whether or not it's a solution from an Express product, and keys off a bunch of "pseudoextensions" to determine icon. (The "pseudoextensions" are also used by the Visual Studio Version Selector applet to pick which DevEnv to launch.)
Note how they're all initially keyed off extension though.
Mac file types have been mentioned here before, but I'd like to point out one thing about them that makes them less than useful. Within Windows, you can change the type of a file just by changing the extension, which you can do if you can rename the file. Within UNIX, you can only grant the X permission if you have permission to do so, but if you can modify the file you can change what type it presents as by working different magic. Mac on the other hand has up through System 8 no way to change the 4-character type and creator codes associated with the file built into the system itself, nor through System 7 was there an easy user-accessable way to change which application was associated with a particular set of type or creator codes. Which led to the interesting case of me not being able to preview the Web pages I created in HomeSite or PageMaker or whatever the hell crappy program it was in an actual browser like Mosaic or Navigator, because Apple Knew Better.
-
@DaveK said:
Well, actually the worst possible thing that could happen is that it might succeed to open in the target program - but then behave differently than expected owing to being capable of carrying unexpected (e.g., rich or active) content types.
Actually, the problem with that is having a WMF file (or any non-executable file, really) that can do the popups and stuff, having it include actual code and all that. Now to be fair, you can't protect against all buffer overflows and other things that might let files opened in certain programs do bad stuff, so I can sort of see your point, and you can't get rid of WMF files now that they're here, but personally I think a better solution is: You have a hardened WMF renderer (that checks the list of calls and makes sure they only go to GDI) and some much clearer way of showing what type of file a file is (like a dialog, as Nautilus has, showing a warning if you try to open a file and the extension doesn't match the file contents - or making sure the icon and always-visible file type description are set by the same code that finds the program to open it, so at least you'll see a WMF icon on the MP3 file and notice that something doesn't match up).
-
@ender said:
Font files. Even when most of them have extension .ttf, Explorer will examine them more deeply to see if they're OpenType instead of TrueType, and if they are, give them a different icon.
HKCR\ttffile\shellex\IconHandler\@ = {BD84B380-8CA2-1069-AB1D-08000948F534}HKCR\CLSID\{BD84B380-8CA2-1069-AB1D-08000948F534}\InProcServer32\@ = fontext.dll
FontExt runs the file through a brief series of algorithms to see if it's Type1 (A), TrueType (Tt), OpenType (O), a TrueType Collection (Tt), an OpenType Collection (O), or unidentifiable (a). If it can't figure out the answer, it looks up its own reg key to find the icon to return.
The algorithms themselves are ridiculously simple, mainly consisting of checking for Type1ness using magic bits, checking if it's TrueType using magic bits, checking for a digital signature (and nothing else) if it's TrueType for it to declare OpenTypehood, and checking to see if there's more than one set of TrueType tables (for collections).
Get rid of FontExt or the IconHandler reg key and you're back to dumb Windows assigning things a lowercase a based solely on the extension.
-
@TooWhiteAndNerdy said:
*solution to a problem that's probably only in my head, and I've never heard anyone else complain about.
The numbers-as-numbers based ordering is called StrCmpLogicalW() in code and, precisely because other people have complained about it, you can turn it off through Group Policy or TweakUI, by unchecking "Use intuitive file name sorting" in Explorer settings.DIR is oblivious and sorts the same way as LS.
-
@burntfuse said:
I don't see what the security risk of filename extensions is, or why it's scary
Mostly because you're relying on cosmetic data (the file name) to identify the content you get attacks like open naked_pics.exe.jpg as email attachments (with instructions for stripping the .jpg of the file name), where-as magic number approaches have the identity of the file type mixed with the file data, which is harder for a curious recipient to change, opening it in notepad risks damaging the binary part of it (presuming the virus is an executable or COM file).
-
@mallard said:
Except that if you recieve your file in an archive (hardly unusual), the execute bit is (almost always) preserved...
True, and a good point. (The archive itself wouldn't be executable though.) You'd still have the extra defense of having to manually unpack the archive first, but I agree this could be a possible attack vector in the future ("Hey n00b Linux user! Here's some pics of Britney having sex! I put them in an archive for your downloading convenience; please unpack and double click any pic to view them in your favourite application!"). I'd have to run some tests to see how the various Linux file managers would handle that, it's almost too obvious to work ;-)
-
@Monomelodies said:
I'd have to run some tests to see how the various Linux file managers would handle that, it's almost too obvious to work ;-)
Most by default would try and render a thumbnail of the image, unless it happens to be an executable then you get a gear (I think). Thunar confirms this, I have neither Gnome nor KDE installed, so I can't test their file managers. I'll try out endevour2 later on.
-
@Aaron said:
Aside from being a massive inconvenience to 99% of computer users, it doesn't even really accomplish anything. It would be a pretty nutty coincidence if a data file, accidentally executed, would run long enough to actually do any damage.
FilenameIntendedToMakeMeCurious.jpg[.exe]? My main point was that the extension is made important, but is hidden by default. That's the biggest part of the security risk (how many users know how to turn this "feature" off?).
@Aaron said:
You can "uphold" whatever you want, but I've never heard of any credible experts in the security field whining about file extensions.
I seem to vaguely remember a not-insignificant number of large virus outbreaks exploiting this.
-
@Lingerance said:
... attacks like open naked_pics.exe.jpg as email attachments (with instructions for stripping the .jpg of the file name) ...
I believe the more common occurance is an attack like a "naked_pics.jpg.exe" attachment - which, with windows default extension-hiding behaviour, displays as "naked_pics.jpg" and runs an executable.
Extension hiding can be useful; I remember seeing (before windows 95) cases where someone had renamed (e.g.) "story.doc" to "oldstory" and then complained that their story was broken.
There's a compromise that I've seen in some other file managers where the extension is left unselected when you go to rename a file - you can still change the extension if you want to, but you don't have to do extra work to keep the same extension.
