From Windows to UNIX: File Extensions
-
Transitioning from the Windows System Administration world to the UNIX System Administration world (including Linux) comes with many stumbling blocks. Many things that seem common or ubiquitous to people who have grown up around Windows can be quite surprisingly different on other systems. One of the most surprising differences to Windows converts is that the concept of a file extension, that three character extension that comes after the dot at the end of a Windows file name, is purely a "Windowsism" and exists nowhere else.
Examples of this include:
MyNotepadFile.txt coolgame.exe alittlescript.bat config.xml myfirstspreadsheet.xls
The dot extension format of Windows is a vestige of the DOS era that has carried on and become so entrenched that no one seems to even think about it any longer. It is a product of the limited power of 1980s eight bit desktop computers. It is complex and problematic. It's also ugly and cumbersome, so much so that Windows, by default, hides it in the Windows Shell making things much harder for end users as they need to understand unnecessarily complex concepts such as extension hiding, double extensions, renaming extensions and concepts such as extensions becoming disconnected from what the file does (try renaming a text file from something.txt to something.xls and Windows is instantly confused and thinks that the file should be opened by Excel rather than Notepad!)
In Windows systems a file is considered to be a type based on what it is called, in non-Windows systems a file is considered to be a type based on what type it actually is.
Outside of Windows, no one uses the extension concept. It is supported for people who want to maintain it or need cross compatibility with Windows, but it is ignored and serves no purpose on a UNIX system. Instead, UNIX determines the function of a file by looking at the file rather than being told what the file might be. This is more reliable and safer as there are fewer components to fail and no human element attempting to maintain the relationship. File extensions are a commonly utilized interface weakness used to trick humans into thinking that a file is something benign when it is, in fact, dangerous. And the Windows Shell will aid the malware in this by converting an incorrect and often hidden extension into a graphical icon that is displayed to the end user that confusingly is displaying an icon based on the name and not what the file actually is. Windows requires a lot more effort, understanding and diligence from end users in this case. UNIX simplifies this dramatically, but can be surprising to those who assume that extensions are a necessity.
It is not completely uncommon to see file extensions on UNIX systems, often because they can be handle for designating a use case such as showing that a file is meant to be a log and not just a text file (in Windows these would both be .txt types and not as expressive) such as:
system.log
But if we use the file command on UNIX to look at system.log it will tell us that it is an ASCII Text file, for example.
# file wpa_supplicant.log wpa_supplicant.log: ASCII text
If we look in the RHEL or CentOS log directory, /var/log, we will see that most files do not get called something ending in .log, but a few do. It is not common or needed in any way to use the extension but it does not hurt anything either.
Once the shock of extensionless file names wears off, most users find it to be easier, safer, cleaner and more efficient and the lack of "hidden" portions of file names makes this aspect of UNIX systems significantly simpler and easier for everyone from end users to power users to administrators.
If Windows Admins find it surprising that UNIX does not need file extensions to tell the OS how to handle a file, imagine how confused people coming from outside of the Windows world are to find that Windows has this archaic holdover and confusing complexity that was shockingly confusing and cumbersome even by the 1990s.
-
So - question, With MS pushing Windows 10 so hard, do you think they could reach a saturation level where they could at some point remove the reliance of an extension for execution of association? i.e. not needing .docx to know it's a Word file?
-
@Dashrender said:
So - question, With MS pushing Windows 10 so hard, do you think they could reach a saturation level where they could at some point remove the reliance of an extension for execution of association? i.e. not needing .docx to know it's a Word file?
At this point they have a major cultural shift to fix as well. They extension is so entrenched that just getting Windows 10 out there is not enough. They need to change how everyone in the ecosystem things.
Eliminating a need for the extension is a start, but just because the OS doesn't need it doesn't mean that applications won't for aeons to come. And users will be confused. How do you transition?
-
I'd say that MS has already started moving users away from caring, as you mentioned because MS has been obfuscating them since XP.
My users definitely don't know what they are or what they do. Granted other legacy apps might take longer, and Windows can leave the system in place for third party use.
I agree it will be an uphill battle, but sounds like one worth making.
-
@Dashrender said:
I'd say that MS has already started moving users away from caring, as you mentioned because MS has been obfuscating them since XP.
They did long before that. But they haven't yet started removing the dependencies. If they want to change the culture, they need to make it make sense for developers to be changing how they write and they need to do that long, long before the change is complete.
-
@Dashrender said:
Granted other legacy apps might take longer, and Windows can leave the system in place for third party use.
Can they, though? Then the system has conflicting info. The extension says it is one thing, the system says that it is another. That's not something that they really want to deal with, but might have to.
-
At least you know I'm reading this carefully.
Another typo
But if we use teh file command -
@Mogrith Glad that someone is!! LOL. Thanks, it's fixed.