Windows does care about file extensions but is mildly embarrassed about it, hence the "show" default that has existed from Win 8 (?) onwards.
Linux and co generally work with magic bytes which is just another way of doing file formats. Is it better to signify your file format with a .ext or otherwise?
I find myself turning on file extensions if I have to use Windows and on Linux, I don't care and it just works.
I think the UIs for Linux are better. I think that MS are hung up on trying to suggest their stuff so it gets in the way a bit. On Linux, you just get the best option based on what is installed.
I have gone and ticked the “stop hiding file extensions” since they were introduced in ~98 (or was it Windows 95?)
When antivirus weren’t widespread, having a person click on a virus was just so easy: create a program with the icon of an image file. God forbid people learn that .exe means executable program. Learning new stuff is scary!
> I have gone and ticked the “stop hiding file extensions” since they were introduced in ~98 (or was it Windows 95?)
I think Windows 95, although even selecting that option still hides some file name extensions (such as ".lnk"). However, I have found that it is possible to use the registry editor to force all file name extensions to be displayed.
But even on system where they aren't needed they're useful IMO, for me as a user. Magic bytes mean you have to seek into each file, and if you care about file types, it means anything that lists files has to do that.
I personally am of the opinion that both make sense and should exist. Extensions are for a first pass filtering/displaying, while magic bytes should be the source of truth, which is extra important when parsing a file anyway. Linux's binfmt_misc[0] even supports matching on either.
Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency.
The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file.
With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap.
As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though.
While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS.
A cheap operation is still infinitely more costly than no operation at all though. And not everything is on a local SSD, even just with a NAS, not to mention FTP, I really wouldn't want there to be no file extensions.
How would webdev look like? At first the HTML goes into "document", the style into "style", and before you know it, you're re-inventing extensions as prefixes or suffixes anyway, and I prefer users.sqlite to users_db. I honestly don't even see a problem to solve, so even the "cheapest" solution seems needlessly costly to me.
I don't see file extensions as a problem to be solved, either. My point is, it's nice that Linux (esp. Desktop Environment) ecosystem embraced magic byte parsing as a solution where having no extension creates problems.
I'm just happy to have the option around, I don't want to deprecate or against file extensions.
If you're interested, I can run some benchmarks on NFS and FTP as well, however.
reply