File suffixes: Who needs them? Well, this guy did Welcome to another edition of On Call in which minnows get munched and a Register reader recalls the headaches caused by the file extension shenanigans of a certain tech giant. Our story today comes from "Rob" (not his name) who was working for a London-based tech company recently snapped up by one of their commercial clients …
File extensions are a horrible anachronism. I can’t understand why they’re still needed in most cases (all binary files should have a specification which mandates the use of a magic number - that some don’t just means that the specification of these outliers needs updating).
In fact the only possible use-case I can see is for text files which might contain different content (c code, c header) but even that might not be necessary in many cases - it should be possible to identify html or xml just by looking at the first few characters.
Extensions and the workaround of enabling them to be hidden just brings confusion and dismay. It’s a nasty throwback to the days of CP/M!
They are handy for humans to see from a list of files what they might be.
But equally they are a dumb idea to use for what happens with them once you get in to execution of binary/script. And DUMB with a monster-sized D when you look at MS's bone headed idea of hiding the extension but still using it to decide what to run if double clicked. Morons, morons, morons...
Exactly, a bugbear of mine since day1 ( of windows i guess) , and they're still doing it now!
My fingers used to be able to tick that box from muscle memory
It might look "nice" for the users to hide extensions , but its a reckless security hazard if you ask me - hello.txt.exe , plus a serious handicap to using the computer in general.
Of course we cant blame Microsoft entirely. There is somebody in every enterprise ticking boxes for whats hidden and whats allowed and how the windows build is set up.
And despite my protests, back in the old days when I used to give a shit , the powers that be would never enable file extensions due to , apathy , ineptitude , stubbornness , "best practice" or maybe some higher wisdom I'm unaware of.
Also, what is very un-nice is to have extensions hidden, then have files such as BlahBlah.txt, BlahBlah.pdf, BlahBlah.exe, BlahBlah.htm, BlahBlah.ini, BlahBlah.zip, BlahBlah.gz, then all you can see in your directory is BlahBlah, BlahBlah, BlahBlah, BlahBlah, BlahBlah, BlahBlah, BlahBlah.
If I recall, the worst thing Microsoft did in terms of file extensions wasn't allowing the hiding of ".exe" or other general executable extensions on files - at least they would typically stand out and the user could avoid these tricks by showing file extensions.
No the nefarious trick that Microsoft handed hackers on a plate was the dreadful SHS extension.
The mere mortals who actually use the computer - in Microsoft's infinite wisdom - shouldn't need to know what goes on behind the curtain. As such, SHS files (shell scrap object file) had hardcoded hidden extensions (like lnk files - hidden by registry entry, not toggled by normally accessed file extension) - and because they were hidden by a single entry, the shs extension either stays hidden, or all your shortcuts show .lnk on the end, along with every other hidden extension.
The problem with SHS files was (aside from the fact they look a lot like a notepad/wordpad document) - they were executable files.
So "readme.txt.shs" would appear as "readme.txt" and an icon similar to the notepad page, however double clicking the file could allow the computer to be compromised/infected.
Thankfully this file type was removed by Vista (yes, something good actually came with Vista) but the fact that this security oversight existed in the first place highlights one of the many major flaws with companies like Microsoft and how they view the users.
"MS's bone headed idea of hiding the extension but still using it to decide what to run if double clicked."
I'd used KDE's Create New facility to create a LibreOffice text file but not noticed when I renamed it that I'd overwritten the whole of 'LibreOffice Writer.odt' instead of just the first part, leaving it without the extension. LO opened it OK and saved it, the GUI showed the correct icon. Nothing I used needed to see the extension to know what it was. I didn't notice at all until someone I'd emailed it to replied to say she couldn't open it with LO in Windows.
Funnily enough in my amateur way that's been my thought for a long time.
Either file extension names are irrelevant or they need to be visible. And since some programmes save files with their own extensions/formats rather than a standard one, I find this essential. Photoshop ( Elements) defaults to a proprietary format. Which is fine until I need it in .JPG to organise or share. So I need to see which is which. My old camcorder used to save files with its own extension - which then had to be renamed to the normal one for that format before I could edit them. The format was standard, they just used a different extension in the machine!!!
IOW For me they are useful to see what kind of file I'm messing with - so why does Windows hide them from me?
Showed the file format by the icon - and generally read the first few bytes to check the file format which is embedded in a lot of format specs. Extensions weren't needed.
Different type needed - some fabulous shareware and full photo editing suites could do that for you.
In 4MB, where a 40MB disc had a full office suite, 386 emulator, and games etc taking up 5-6mb.
While ago now ...shuffles to door...
The original RiscOS ADFS:: albeit some less nice quirks like that inconvenient 77 items per directory limitation indeed had lots of merits and avoided quite a lot of issues.
AmigaDOS also has filetypes embedded in the header, eliminating the need for name extensions, although most programs still used extensions for convenience. This could lead to opening a picture *.IFF (DeLuxe Paint) with audio software and vice versa. Still does a better work on things named *.exe and not being one with error code 121: file is not an object module.
This is a challenge any MSDOS PC known to me is sure to fail.
Back to C64 times, the endings were seperated from the filename, although readable in the directory, and not necessary to access the file, if not different filetypes with same name existed. Still it was useable to know wether to open a PRG,SEQ,REL or whatever type although the LOAD "name",8 command would automatically select the *.PRG file, even if a *.SEQ file with the same name existed..
File headers did indeed implement some additional information, though it would not always be used. Load one of the then most used "soundmonitor" files with "name",8 would load it from address $0801 while loading the same file with "name",8,1 would put it rightfully upwards from $c000 / address 49152.
So, in short, visible file extensions if the OS does not already show the correct filetype via icon or other means were never useless.
PS: Of course there are can bee unwanted situations when the OS will not allow the user to change filetypes, no matter what (looking at YOU, Apple macintosh, as all your disciples came to us puny amiga guys to re-set corrupted filetypes because your "i know better than you" OS would not allow them to...).
Long, long ago, a friend lent me his RiscOS machine so that I could port some SunOS C code. It took me a while to get the hang of extension-free .c and .h files. Before I got to that point, I typed in
delete *.cor whatever the RiscOS delete command was (as I said, a long time ago). Anyway, it wiped the whole fe**ing disk.
Because you're just a DUMB user who can't POSSIBLY have a need to know what your computer is doing, perhaps? Or, at least, that's what it feels like the geeniooses at M$ think about their victi... customers.
Remember, these are the same people who think that no user ever needs more than 4MB of RAM, and go out of their way to make sure that's all you'll ever have available.
Windows displays the Application right next to the filename in the column labled 'type'. It tells you, right there, what happens to them.
I can understand that people might want to be told twice. Might want to see '.xlsm' as well as 'Calc'. My like to see the file extension as well as seeing what will happen.
But if you can't see what's right in front of you, I can't say that I blame MS for that.
No. Windows tells you what software is associated with that file.*
Which is often just the programme that Microsoft wants you to use. e.g. Edge browser. Assuming that there is a programme associated with that data file, of course, which there might not be if, for example, it's a stand-alone/portable application.
*Assuming it's a data file and not an executable of course. As in "Something-innocent.txt.exe.
"it should be possible to identify html or xml just by looking at the first few characters" so you have to open the file??? Trusting the OS to identify it is recipe for disaster and doesn't work in a text interface.
How about you have a simple convention, say a 3 letter label on each file so it's easily human readable in every context to at least get an idea of what it contains BEFORE you look inside it.
They never should've been hidden imho, that way lies pain and confusion.
"it should be possible to identify html or xml just by looking at the first few characters" so you have to open the file??? Trusting the OS to identify it is recipe for disaster and doesn't work in a text interface.That's literally what the `file` command does.
Reading data from a file is not inherently dangerous. What's dangerous is executing instructions from an unknown file.
> This is true. But even reading data can be dangerous - although I’m don’t know of any vulnerabilities in file off the top of my head.
There have been a couple of "text of death" type bugs in Android and iPhone that meant nasties could happen simply by receiving a text. And there has been at least one image format exploit where opening a crafted image triggered a buffer overflow exploit. And, most recently, even logging (in Log4J) data can cause grief.
This is true. But even reading data can be dangerous - although I’m don’t know of any vulnerabilities in file off the top of my head.
Only if you live in Missouri and not in the way you thought.
Of course there are vulnerabilities -- well known and repeatedly documented buffer overrun errors on all kinds of read-only files, including unix script files. The file recognition system was a well known security vulnerability of unix systems -- so well known that it's been mostly fixed. It's been, what, a decade or more since the last known exploit.
At Doctor Syntax, re: real operating systems.
I'd add to that concept that, in addition to the use of a real OS, it requires a computer user with the knowledge of said OS to be aware of the command in question. There's a world of difference between someone tech savvy enough to be running Linux & knows of the command, versus your typical Windows (L)user whom doesn't (Care/know) enough to tick the box in the file explorer options to reveal the hidden extensions.
Remember folks, the readers of this site are not the target demographic for such OS/commands, it's talking about the average Windows user that can't be bothered to RTFM much less even acknowledge it's existence. =-J
Reading data from the file does update the file metadata, which means the "last accessed" value in the filesystem would be useless.
I'm splitting hairs here, but there are all sorts of vulnerabilities where systems attempt and fail to interpret data in the file where the user had no intention (or was given the choice) of executing the file. Stagefright on Android, for one.
"Sure thing boss"
/proceeds to open five million file handlers to read two bytes off each one
Versus looking at this thing most file systems have where things such as file name and where on disk they are, size, etc, is stored.
Yeah the first way is certainly the way to go. Wonder why no one thought of that before.
The main problem with reading the first few bytes of a file to show what it is/does, is that when listing the contents of a directory, instead of just reading the page off the disk that contains the filenames, you then also need to go off to the disk sector that directory entry points at, and read that too. That might not be a problem for situations where you only have a dozen or so files in a directory, but if you've got a lot of large files in one directory, all on different physical disk sectors, that's going to be slow, and also wearing on your drives. OK, this doesn't cause such an issue with SSDs, but the idea of pointless and inefficient disk reads is still idiotic.
Intentionally storing part of the file data in the metadata is a step in the wrong direction. You are right that there is no technical reason not to do it; after all, to the disk drive data is data.
What problem were we trying to solve again?
@ali dodd
Damn! Absolutely correct - have a thumbs up. Of course it could be unwise for the OS to have to probe into each file to get its type. That way malware lies. So the only issue is the hiding of the extension.
So obvious. So right. I’m going to blame my previous oversight on the fact that I’ve currently got Covid and any thinking is hard work.
(Shuffles back to bed in disgrace)
*Hands you a tankard of chicken broth, capped with a "sippy cup" topper to prevent spills, & a "CrazyStraw" stuck in the straw hole through which to enjoy the broth*
Drink up, get well soon, & use the down time to catch up on all those archived BOFH episodes you've always wanted to read but never had the time.
=-)
Inspecting each file has two disadvantages over using metadata: It's slower, and it's heuristic, aka educated guesswork.
Yes, a defined magic number would be beneficial, although the OS should keep this in metadata for quick access. However, this would require a central registry of known file types (a 64 bit number might just be enough).
Also, the .EXE (etc.) extension indicates that something CAN be executed, not that it SHOULD - it does not imply any security assertions.
RISC OS on ARM (whatever happened to them?) used a 32bit metadata number to identify the file, IIRC the first 16bits was the software vendor and the rest used for whatever they wanted to identify it as
It also meant that lots of different packages could have bak files without clashing
"Trusting the OS to identify it is recipe for disaster and doesn't work in a text interface."
Which is correct if you speak of primitive MSDOS PCs. Name anything command.com and/or MSDOS.SYS, replace the aforementioned files with the junk you named so and watch the PC crash without a single sign of what went wrong at the next reboot.
Try this on a RiscOS System and you will be rewarded with the information that the desired file is not executeable.
Try it on an Amiga and there is the nice error code 121: file is not an object module.
File headers are there for a reason. Wether you "trust" the OS that it can associate the file header/file type with your desired application or "trust" the OS that it will at least know how to handle a falsely named file (*.COM instead of *.txt as described above) is sadly not up yo your choice anyway.
Once had a nice chap of German descent at our offices trying to install a new version of their software for me to Beta test. He’d arrived that morning from the USA with his laptop, a few CD Roms and assorted cables. He also brought with him a bad case of Jetlag and an attitude to match when things started to go wrong.
Things went wrong rather quickly because the freshly burned CD Roms were not allowing him to install his software in my test PC. He blamed my computer and then to demonstrate got his laptop out and tried it on that. That didn’t work either which he was seriously unhappy about and lead to more grumbling. He said he’d have to contact the office in the USA to see what was going wrong but no one would be there till after lunch in the UK.
I suggested having lunch and then worrying about contacting those across the pond afterwards. He reluctantly agreed and asked about where he could buy it. I mentioned there were a few sandwich bars nearby, a few restaurants and we also had a staff canteen where I was going. He didn’t seem keen on leaving the building but had questions about the canteen.
“Do they sell Sandwiches?” - Yes
“Do they have non carbonated beverages?” - Yes
“Can lunch be bought for under £5” - Yes
“Do they supply receipts?” - Yes I believe so
“Are there places to sit down?” - Yes
Those answered we ventured to the staff eatery for lunch. He explained that his company has a $10 meal allowance for lunch when “on the road”. He needed the receipt to be able to reclaim this from the firm. Furthermore because nothing was installing and he hadn’t identified the issue, he was likely to be here overnight. This was an issue because he was booked on a flight back that night to the USA. He had to get authorisation to change that and find + book a cheap hotel room for the night. Buy some underwear and a toothbrush as he hadn’t brought any clothes/wash kit with him On top of all of that he had to explain to his wife that he wouldn’t be back that night - hardest one to do.
He talked to head office after lunch and got his authorisation. His wife was quite unhappy given the shouting coming out of his cellphone. Sadly staff at headquarters didn’t have a clue as to why it wasn’t working. I said I had to go to a meeting and left him with the IT department phone number and another member of staff as a chaperone. When I got back he had installed everything and was just customising the system for us. I asked what had been wrong and he muttered something about truncated file names. It turned out that one file name was missing a digit at the end which had been truncated on the CD Roms. This stopped the installer as it checked all the files early on in the process and stopped when it couldn’t find one.
On the plus side as this was now a two day trip he had a further $20 in expenses, to spend on dinner. He said that he needed to buy his wife a nice souvenir to placate, her so was off to Harrods. The software was described beautifully by a colleague of mine as “Not even a Beta version at the moment, who wrote this buggy piece of crap”.
Oracle then?
The ones that insist that on all localized versions of Windows the local admin group is named "Administrators"?
And when you point it to them also insist that no other client had any issue with it, when you know that you are the only one using that version?
Larry almost lost his right to enter a sailing competition over it :-)
This stopped the installer as it checked all the files early on in the process and stopped when it couldn’t find one.
And presumably didn't report which one was missing/allow installer to locate it from elsewhere/skip installation if non-essential or already present.
Small rant coming.
Some years ago I stopped ever buying anything by HP. Because I'd had a printer. Which tried to upgrade its drivers and bloated software. And started the upgrade by removing all the previous files. Then failed to install the new ones because one of those previous files was still in situ. Nothing would remove that file. (With hindsight I should have booted into my PC with 'nux and then tried but this was many years ago now.) Nor would it allow me to install into a different location. Nor would it skip over that file and try with the existing one still in place. Which was particularly annoying because it had the same f****ing version number .
</rant>
Worst thing I had was with Microsoft, with SQL Server.
There was a known bug in one part of the software, that was corrected in the US package, with a small increment in the DLL version number.
Installing the software in Europe using a localized version, I ran in the exact issue corrected in the last US version.
Checking the DLL (localized), I saw at first it was the proper version.
Looking deeper, I discovered it was in fact the previous buggy DLL with an updated version number...
Add to be sent by snail mail a disk with the proper DLL to be installed on the client system, waiting 2 days out of a planned trip of 5 days...
Don't worry, HP have fixed that now with the "HP Smart" app - pretty much any HP printer now will insist on you installing the HP Smart app in order to work with the printer.
As an alternative, they have the HP easy installation program, which helpfully directs you to download the driv... sorry, no, it downloads the HP Smart app again.
The HP is perfect, except when it isn't - which is more often than you would hope. When it doesn't work, you quickly discover how smart it isn't.
Like many other apps from the windows store, it's designed to just work, and when it doesn't, it isn't designed to handle that.
HP know best however - or at least that's what they believe.
Nowadays, file extensions are not really used by the computer — they're used by humans who want to know the file format. It's a buggy system, since the extensions can be wrong. The Word document can have .txt extension, the .html file can be a JPEG.
When you are using a GUI, you can have icons that do the same job, but you are not always using a GUI; the GUI often just repeats what the extension claims without checking; and the GUI might not even understand the proprietary format.
But personally, I'll keep using extensions. I'd rather have some indication of what the file format is, and hope it was set properly, rather than having to guess every time.
Of course, that never stops people thinking they can change a file type just by changing the extension. I had that recently on a website I built for a client where one of the client's staff had "helpfully" renamed some PNGs to a JPG extension and then complained that some resizing code wouldn't work on the affected images. I added a "deep code" check along with a warning when images were discovered with the incorrect extension.
>Of course, that never stops people thinking they can change a file type just by changing the extension
So why can't it ?
It's an unambiguous task that was described succinctly
It clearly indicates the user's requirements
If you are going to use extensions to indicate type then it's the obvious way to indicate a type conversion
It's like saying "some idiot user thought they could copy a file to a new folder by just dragging the icon - rather than editing the filesystem metadata with edlin - lusers!"
Unambiguous?
When converting a PDF or PS file, say to a raster, you need to specify the resolution. Converting to a picture file? Please specify resolution, colour space, etc. There are several PDF formats out there, different versions and things like "archive" or embedded colour calibration info. Inkscape has its own superset of svg commands, as probably do other programs. And those are just a few examples without really thinking hard.
Unambiguous? Yeah. Right.
What do you think of CSV files?
It is supposed to means "Comma separated values".
But on Windows system, it will use what is defined in your regional settings, so in countries that use a comma as a decimal separator it won't be properly recognized...
And when you work with people all over the world, you can be sure that what is sent by one guy won't be immediately readable by the recipient.
If only the systems could open automatically TSV files...
And when you work with people all over the world, you can be sure that what is sent by one guy won't be immediately readable by the recipient.
I had that same problem within one office with two different settings, one for home staff and one for the foreign born staff (both ex-pats and permanent immigrants for marriage) and another setting for the office in a third country, so .csv files exported from the AS/400 would fail for some users no matter what. The solution turned out for the AS/400 to prepend the actual .csv file with a line of five characters, "sep=<separator>". That solved that problem, immediately followed by the next: the decimal separator, for which there is no such work around.
Magic numbers are not reliable either. There is no universal location or format for the magic string and so files can and do get misidentified. At least with extensions they are under the control of the user.
There are plenty of other cases too, such as layered formats such as .tar.gz or formats that package multiple elements in a single .zip. Using magic all you see is the outer container.
Finally it's an expensive way of doing it. Every file needs to be read and compared against a long list of possibilities. What if you are looking at a remote FTP server for example where you want as many clues at the directory level as possible.
"There are plenty of other cases too, such as layered formats such as .tar.gz or formats that package multiple elements in a single .zip. Using magic all you see is the outer container."
This can be dealt with.
.odt, for instance, is such a format. A few bytes into the file are the strings 'mimetypeapplication/vnd.oasis.opendocument.text' and 'content.xml'. Likewise a .deb starts with the string '!<arch>' and then continues a little further in with strings indicating the contents.
The system is capable of using this.
Magic numbers embedded in the file are an ugly workaround. One old idea is to put the file type indicator is in the file descriptor - like the executable bit in *nix.
I recall that Digital RMS did something of the kind. But I also recall that VMS disks tended to contain lots of files that were simply untyped streams.
Magic numbers are not reliable either.
Just the other week I found out how unreliable: it turned out that Apple's fat binaries and java class files use the same magic number with a hex character sequence that more than one person apparently found cute.
It looks like Apple discovered the cuteness earlier, but by the time Java people got into the game Apple didn't interest anyone so no one checked, I guess.
Details can be easily found on the interwebs or in the magic file (on Linux, but not on macOS, for some reason).
They can if they are generated centrally.
Apple (say) could give out 64bit id to everyone who registers an Apple account, any apps they distribute have that number in their metadata. Then you have another number you use to identify what type of file this is for your app
You can even roll in digital signatures, so not only do you recognise this number as a microsoft doc file you could prove that is was written by a microsoft signed binary.
I am on the complete opposite of your opinion: Whenever a programs install updates, quite a number of them take over PDF JPG JPEG PNG DOC ODF DOCX etc without asking!
Now if you use that "magic" you whole picture folder suddenly contains "Adobe Photoshop Picture" instead of "JPEG Picture". Andf they all open with the wrong program istead of the picture viewer. With the extension you see what ist going on. Same for PDF: Which browser took over PDF without asking again?
On Mac, where the file stream is used, this happens on a regular base. Hence even Apple shows the file extension and uses it!
On the next level: How do you coordinate your magic across those many OS-es around there? Do you want to create a new standard to replace all competing standards?
I've noticed that only AH companies do this helpful conversion. Instead of anything Adobe or MS and having extra work to do fending them off from molesting my files, I use alternatives.
Affinity Photo has not changed anything, it does use its own suffix if I save developed files as such, nor have the other graphics programs I have used in my workflow, including other commercial ones like Capture One or DxO.
LibreOffice doesn't molest either.
Funny how it's all the companies I'd ban from any government branch if so empowered. I did have to disembowel iTunes on this older version of OSX to open music files with something else (BTW, right-click on iTunes>>Show Contents>> put contents in Trash, icon remains but is an empty shell, sorta like a Tory PM)
all binary files should have a specification which mandates the use of a magic number - that some don’t just means that the specification of these outliers needs updating
The Mac used to use embedded file descriptors - each file had a data fork (equivalent to a regular file) and a resource fork which effectively provided a whole new filesystem of metadata.
As a minimum, the resource fork would have two four character fields, well technically I think they were just 32 bit fields but convention said they were human readable strings. One was the creator - the application that made it; the other was the type - the specific type of file (e.g. TEXT). Other stuff in the resource fork would include all the icons, dialogs, etc, etc for an application. With a suitable editor, you could do some "interesting" things by editing these. It also meant that a text file created by one program could have an icon specific to that program, and open (by default) with that program - quite separate to text files created by a different program.
It was a brilliant system, but it was a right royal P.I.T.A. with anything but an Apple filesystem since other filesystems simply didn't have this concept. Apple did have workarounds, but these typically involved having a second file to hold the resource fork - so MyTextFile and _MyTextFile. Needless to say, it was hard for a non-Apple system to lose these other files, it confused users, etc, etc. So in the end Apple had to admit defeat, resource forks went away, and once again inferiority won the day. Now OS X uses extensions to identify the file type.
On the contrary: NTFS does support this system, at least since Windows NT 4.0 - maybe even before. It is implemented by using "alternate data streams", which can be anything and not just 32 bit. Currently, since Windows XP some service pack, it is used to mark downloaded files from the internet as "came from the internet". If you right-click and check the properties on a downloaded file you will have an extra flag next to "Archive" "Read-Only" "hidden".
For more information: ask DuckGoGo!
all binary files should have a specification which mandates the use of a magic number
I agree, it's so much easier to open a file up in a hex editor, and then look up the first few bytes in a great big lookup table, which would never be out-of-date. What sort of idiot would want to quickly and easily establish the type of a file just by looking at the extension?
In case it had escaped you, that was irony. Binary file identifiers are good for machines, when it's machines reading and writing the files. Most of the time, though, it's humans using computers, and fleshbags have different requirements.
Not after XP, whereas no action of any consequence has more than a 50% chance of you being allowed to perform it, regardless of what you try. Frankly, I'm way tired of not being able to tell my own PC "DO NOT EVER DARE TO ASK ME AGAIN ABOUT ANYTHING THIS PARTICULAR PROGRAM WANTS TO DO, EVER, NEVER. JUST LET IT DO IT. YOU FUCKING PIECE OF FUCKING SHIT."
I'd write my own script to set any version of windows to my preferred settings , and host it some where accessible .
but the issue would be the same:
you're probly at work , which would mean running / installing that through an ever incresing number of security precautions
which might not be worth it for the time you will be on that machine .
I remember when Microsoft did that trick of hiding the extensions, I was working on something using file names like:
projectname.txt
projectname.doc
projectname.xls
Oh fun! Yes, I could have learned to differentiate the subtle variations on the icons, but life's too short: I enabled extensions.
They are useful for ordering data in a directory / folder / whatever you want to call it.
Very handy to search by extension.
Only problem with filenames is windows default of hiding them, irritating when app, config file / manifest etc then all appear just as the same name (as only the suffix identifies the difference)... and Windows irritating icons for identifying file type are far from ideal.
Haven't used windows in 20 years now but presume the extensions aren't hidden to scripts? I used to have to manage thousands of files and used the extensions to inflict a series of commands on them and the new files generated. Why have a computer and click on things when the computer can do it for you?
If I'm reading correctly, the problem is the human was seeing "configure.txt" in in the filer window, so typed "configure.txt" in the script, but on running the script it found that the file "configure.txt" did not exist, becase the file was actually called "configure.txt.txt".
If the human had entered "configure.txt.txt" in the script, then yes it would have found the file called "configure.txt.txt". The problem all boiled down to what the Windows filer was telling the human being what the file was called. The filer was lying.
But...it might have been something IMPORTANT. Might have been a letter from the daughter, just with a funny name. Or an update from the investment broker. Or a Thank You note from the oncologist.
Yeah, that attachment could have been anything...never know until you double-click on it.
The real fault lies in MS trying to be too accommodating in Outlook and make things too, too easy for the user. If it could have only ever saved attachments for opening later, 95% of Microsoft's desktop issues would never have happened. But no, let's be super convenient for the user. He's only opening funny letters from his daughter, anyhow...
If MS were so bothered about that they could have changed it so the rename dialog/in-place edit thingy in the list doesn't allow the extension to be changed, unless e.g. you hold shift.
I think current Windows* pre-selects the part before the dot when you rename. If you want to change the type you have to deselect and reselect everything.
* I could be confusing this with Linux, MacOS....
An easy way to prevent unintentional changing of the file extention is a simple one as far as I can see.
"Save" does just that, not allowing any change of filename nor extension, perhaps renaming the original file to $Name.Old_$DateTime, then replacing the original file with the updated contents.
"Save As" allows the altering of the file name, but not the extension.
"Export as" should be required to pick a new extension, at which point you can also choose a new file name as well.
Click "Save" to replace/update the original file, "Save As" to rename it, & "Export as" to change the extension. That way you can't do it accidentally & have to use the correct menu option to even get to the bit where such jiggery-pokery is possible...
"If they're hidden then they can't be changed. It removes the opportunity for fuck ups."
They can still be changed when not using the Desktop UI. Command line, "save as" or any script will do.
In addition, the issue mentioned in the story is quite likely caused by hidden filename extension, which means the OS not showing the "credentials.txt" as "credentials.txt" but as "credentials" which quite likely caused the addition of the surplus ".txt" which was then duly (and hiddenly) rejected by the software searching for "credentials.txt" and not "credentials.txt.txt" which then made the diagnosis a bit harder on a system that refuses to correctly display file names with extensions.
To look more like Apple?
Yes, I get that people's opinion on whether being more like Apple is a good or bad thing may vary but, around that time, Apple's look/feel and general user experience (for the non-techy at least) was better/cleaner. Personally it's not my taste but for many (e.g. my mum) picking Apple over Windows was a no-brainer and I think MS wanted to try and get some back.
You can have that in Windows too. Called "Superhidden". Applies to .lnk, .url and a few more.
In my IT job over 12 years, a lot of the users were a bit clueless, and for some reason a lot of them used MS Word 'open' file dialogue to browse/search for files.
Of course, the file naming convention was just a stupid - a lot of word/excel names were the same, so all the files looked the same.
Enter the guessing game. The amount of times they opened excel files in word, and now the checkmate - the first thing they did was SAVE IT!
In the end my boss told me to ignore any request to restore these files.
nope .
"open file" dialogue file management is a thing .
users will use it to copy delete move rename etc etc
Just like they will use Outlook as a data storage system - including the "Deleted Items"
Just like the amount of times I've asked a user what they clicked to get to this site / app / folder / picture .
Only to have to wait patiently while they dig up a two year old email from their supervisor saying "The new {thing} is at *this* location , make a note"
"They'd have to change the "Type" dropdown to "All Files"
And does that not make "perfect" sense ? Of course you would want to see "all files" when searching some file, wouldn´t you ?
As much sense as the panicked cry "my files are gone" ?
"Where did you save them"
"in Word !"
"I do not care what software you used to make them, where did you save them ?"
"In Word !!!"
And Word(pad) does not show an unlimited list of the last processed documents so once you have pushed the suddenly sought after document from the recent file list, its "gone".
Do not ask me how often i had to teach the difference between "saving" to a "recent files" list and saving to wherever on the harddisk....
I've been railing on this "feature" since the Windows ME days at LEAST. Working front line support for an OEM, and having to talk grandma and grandpa through finding a file and the extensions are hidden is a nightmare. It got to a point that one of our first support steps was to disable "Hide file extensions for known file types" early in any call, and when reinstalling Windows would have the customer do this as soon as possible.
Oh the fun caused by those dodgy 'file save' dialogues, where selecting something like 'file type: *.txt' then typing 'credentials.txt' would save it as 'credentials.txt.txt'
And the fun of forgetting to set the correct 'file type' then discovering 'credentials.txt' is saved as 'credentials.txt.rtf'
Conversation with a usually competent colleague:
Him: I can't import this certificate
Me: Oh really? Let's have a look...
[Quick screen share]
Me: Right, so what you've got isn't cert.crt, it's cert.crt.txt, turn on your bloody file extensions
Him: D'oh, thanks, sorry Outski and rest of the team whose time I've wasted
----> one of many beers owed by the left pondian team for dumbass mistakes
I wrote a nice web app where suppliers could upload data straight into our systems from a CSV file, to save me from 20 minutes of mucking about with awk every time anybody e-mailed us a spreadsheet. I already had a collection of headers, so I used them to make it smart enough to work out -- within limits, but those limits were still pretty broad -- which column was what.
Within minutes of putting it live, I had a customer on the line insisting that it was not accepting their .csv file.
It transpired that, instead of following the clear instructions with screenshots showing where to change the file type in OpenOffice.org Calc and Excel, they had simply used whatever the Windows equivalent of `mv` is to change the extension of an .xlsx file .....
Unfortunately, being stupid is not a disqualifying criteria for using a computer.
And if you think that just changing the file extension from xlsx to csv changes the file format, then you're too stupid to use a computer.
More unfortunately, there are many, many people who haven't got a clue what a file extension means, but they're still employed and using a computer.
That's the employer's fault : he doesn't know what a file extension means either.
On the mainframe we had to worry about sources files in ascii and EBCDIC, and there was a setting which set the code page on the file. The various zip/pax commands did not always work.
Our simple instructions gave a nice little process for doing the work.
Some "clever" Windows expert thought 'I can do this with less typing and make it "quicker".' as a result his data was always in the wrong code page.
My colleague was on the phone for an hour trying to work out what the problem was.
The end of the conversation went
"Do step 1"
"Ok I've done step 1"
"Are you sure?"
"Yes"
"hmmm - what was the response from the command"
"xyz"
"But that's not the response from the command. It looks like you used the abc command"
"Well it works just well"
"No it doesn't it. Follow the instructions"
"OK Ive done step 1"
"Now do step 2"
"what response did you get?"
"That's not the response from the zyx command"
Loop:
VMS did have it's problems though, since devices and files were analogous.
Back in the mists of time when I worked at the local college (now university) we had a student type up a long dissertation about an on-site facility then save it, unfortunately she used the facility name which was also a printer in that facility.
Result was no file and a student in tears.
Once we figured out what had happened we retrieved the print out and got one of the department secretaries (I told you it was a long time ago) to retype it and save it under a different name.
unfortunately she used the facility name which was also a printer in that facility.
Logical names, the VMS equivalent to an environment variable. Won't the same happen on Windows? Save something to "LPT:" (or is it "PRN:" ?) and I don't think you'll get a file of that name. Been a while since I tried, though.
Even in Redmond's latest and shiniest you cannot name a file or folder AUX, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, CON, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, NUL or PRN.
There is a way to create one if you use cmd or powershell and add a slash at the end of the name (e.g. aux\) but it opens another can of worms when interacting with the item
And yet I've still had a user do exactly this...
They managed to create a file which I think was called NUL as it was the abbreviation of a project they were working on. It was much harder to remove than it was for them to create it, I remember that much, and something had to be downloaded to do it (can't remember what now!)
VAX/VMS roolz ok
Didn't VMS (RMS) files also have a file header with metadata which described what the file type was, so you could see if a file was object code, indexed, stream, or whatever? The Unix-style "every file is just a stream of bytes" is why people have to hide magic numbers inline, and tools like 'file' have to make educated guesses.
I've gone through the process of explaining to the noob about the possibility of the file extension being missing, wrong, or hidden. Use 'file wibble.xxx' and you'll get a fair idea of what you are dealing with, not infallible but good for 95% of cases, I say. That's magic they say. Yes it is: 'man 5 magic'.
An ICI power station many years ago with a snazzy new VAX 11/780 optimising the combustion process. VAX/VMS introduced version numbers, so the filenames were all in the format filenames.ext;version (IIRC 9.3;3 characters), every time you edited a file it was saved in a new file with an auto incremented version number which saved many people's bacon over the year.
Space was always an issue as the HDDs were only 128MB, so the OS provided a handy utility to purge the old versions down to a sensible level.
The designers of the system came from PDP land and decided that these newfangled version number things could be utililised for something more useful. So cue a directory filled with files named thus:
tempinput.dat;1
tempinput.dat;2
tempinput.dat;3
.
.
.
tempinput.dat;150
Each one contained all of readings taken every 15 minutes for an individual sensor.
I (being a newbie muppet at this point) typed PURGE/KEEP=5 across the entire disk and left the scene of disaster chuffed at the amount of space that I had recovered.
Surely every VMS user has done that, which is probably why no other OS has ever offered it. If you want version control, learn and use a version control system. They aren't *that* complicated if you restrict yourself to only one branch (ie, a strictly linear history).
Working in a plastics plant with an ancient VAX/VMS system that one day stopped doing what it was supposed to do. Guy who regularly supported it was on vacation so I volunteered to take a look. Found a file that some process updated daily, so getting a new version numbered file daily. It finally hit the maximum version number (65535?), and blew up when trying to save a new version of the file.
The Grand Poobahs over the Atlantic were not fond of their new subordinates' habit of not always following orders (normally when those orders would have resulted in the business foundering on the rocks of IT borkage).
Sounds like someone needs to look up the meaning of "work-to-rule"
I've only had to use it once in 45 years, but it was EXTREMELY effective, especially when I had documentation from my management saying "do whatever they say"
It can be quite obnoxious, and I avoid it whenever possible, but sometimes the "do what they say" directive can be destructive to point of hysteria (on my part) compared to the "do what they thought they had meant". Depends how much of an arse the people involved, especially when you warn them at the first encounter - you sure about that? I keep a backup position in any case - more internal chuckles as I take "some time" to see if their problem can be fixed.
Long ago, I worked with Data General minis running AOS/VS. This had a rich list of file types, and a convention for extensions: OL for for overlay, .EXE for executables, etc. However, it was quite possible for file type and extension not to match. I went spent sometime frustrated at the the cryptic error message I received trying to compile (or was it assemble?) some source. Eventually I discovered that the extension was correct, but the file type was the AOS/VS default, which I think was UDF (user data file). In a case like that, one ran
create/type=aok newfile.aok
copy/append newfile.aok oldfile.aok
and proceeded. I was not the only person to be caught by this--somebody I emailed some C files got bit by it, too.
Working this morning in my repository of random server / website maintenance scripts - and the file extensions provide a nice(?) history of my latest-language-of interest over the past ~10 years.
Starts with lots of .pl and a couple of .sh scripts - moves on to .p6, then .raku, and most lately .py
Am in the process of rewriting them all to python (except for the bash scripts where approprate), so that if anyone else ever needs to take this on from me they don't go mad.
It goes to show, even though PERL was one of the first languages I learned, way back in the day, that when I saw the .raku file extension, my first thought was "what the hell has a Japanese glaze-reducing firing technique got to do with file extensions?"
Maybe we have reached "peak" cute-names-for-programming-languages?
For those who say that file extensions are not needed and it's safe to read files, talk to the car owners in Seattle with bricked radios because someone at a radio station submitted image files (things like album covers) without the JPG extension to the HD Radio system that broadcast them over the FM radio signals. For some reason the Mazda radios tried to deal with the files in a way that permanently broke the radios. Fortunately Mazda has offered to replace the $1,500 radios for free.
https://www.theregister.com/2022/02/10/mazda_radios_images/
This post has been deleted by its author
Mazda and Nissan are famous around here for their "kind" parts prices. The number of vehicles that are sitting on the used floors because the former owners couldn't afford the repairs is quite astounding. A lot of them end up going to auction, too.
I knew someone who owned a well aged Nissan back in the late 90's. The engine control unit went - an $1100 touch that would work out to about $2500 nowadays with inflation.
Once had the pleasure of having a colleague from what they considered to be the most important office screeching at me that I "had configured <software> with a bunch of resources specified" - which was a problem in their office because they had rolled-their-own when it came to allocating shared resource pointers instead of using the computer manufacturer's automatic configurationatorizer like everyone else in the world, and those "specified" resources were "KNOWN to be reserved in the head office".
(I had the job of configuring this software in my office because I took a brief break from the madhouse to work for the manufacturer and knew how it all worked. Would that I had stayed there.)
I listened to the rant and then said I had no idea what the person was talking about as I had simply allowed the software installation to take defaults.
More ranting, until it transpired the person (who was sneakily trying to steal my job wrt this software and - because they couldn't bring themselves to speak to me rather than at me - was unaware I would happily give the job away) was looking at the configuration report file and *not* the configuration itself.
My sweetly delivered "Why on earth didn't you just ask me where to look?" must've been like drinking battery acid to that twit.
One for the old Univac/Sperry Univac/Unisys crowd:
I was once asked to bundle up an application and send it and all the (empty except for configuration data) files it needed to another site across the country (never underestimate the bandwidth of a truck full of tapes barreling down the interstate: Tannenbaum), where "Univac experts" would install the same application and re-configure it to their needs.
I got a phone call a week later from an irate on-site expert: "You forgot to send SYS$DLOC$ ..."
Some centuries back, when Windows95 was still in vogue in corporate environments, despite the incessant warnings of security issues or well, no security, a client organization called for service. A bunch of computers couldn't access the network or internet.
A bit of diagnosis revealed that some bright individual had downloaded malware, which replaced winsock32.dll with something that would've easily been mistaken for a potted plant if it wasn't just data.
So, I find a machine that wasn't corrupted by the malware, which took a bit of doing and in a shortcut attempt, needed to create a share somewhere, anywhere, so that it could be copied via netbeui (don't blame me, I didn't design or support the network, the distant corporate overloards in their fully certified ivory tower did). Alas, creating a share wasn't allowed by GPO, so off I go to call their HQ command center and resident MCSE's. Resistance galore to allowing a share to be created or used anywhere, period and this gem of wisdumb was offered, "Just copy the winsock32.dll from the AS400 disk".
I slowly and patiently explained (we were getting $185/hour, so I was extremely patient, but not as patient with problem clients that paid $100 more per hour for us to put up with them), winsock(anything).dll is a Microsoft product, the AS400 is an IBM product and the two companies weren't getting along or sharing files for quite some time. So, I was offered the suggestion of copying winsock32.dll from the install disk, which was a early release version and we were a couple of service packs in, rendering the suggested solution as effective as replacing winsock32.dll with a text file named to that name.
Explaining even more slowly, obviously realizing that utter morons were now able to acquire the treasured MCSE certification, I explained what service packs were, mixed versions being fatal to systems we're trying to recover, as the malware wasn't persistent in that case and the plant really should resume production before proton decay in the universe and generally gave a full suggestion of my lack of faith in the individual's capability to even utilize a specially blunted infant feeding spoon without self-harm occurring and finally, finally, FINALLY, access was granted.
Operations resumed within the hour, as it was only 100 machines.
The fun part, he was the supervisor, who all non-cookie cutter things had to go through. The company is now registered as a foreign corporation, apparently having failed from California.
I should've become a dentist, as I've had ever so many teeth to pull over the decades!
The hiding of filename extensions seems to be part of the great "dumb-down" of everything in software. Humans are too ****ing stupid to be able to read an extension name so lets give them a pretty pikcher to click on because as we all know Icons are the be all and end all of the Universe as we know it. (Yes, I am rolling my eyes!). If I had 1 Pound Sterling for every time I have had to unhide file extensions and then shown someone what happens when they are NOT displayed, I'd have retired a rich man earlier this year. Does Joe Bloggs need to know what the file extension is? No, but then he will never run File Manager or any other file management program, so hiding the extensions was and always will be an act of idiocy on the part of Microsoft. Those of use who do run File Manager use those extensions and need to see them.
As an engineer ( designing steel and concrete structures) my lawyer brother occasionally calls for support.*
He had a persistent problem logging from his laptop into a set of legal databases. He would log in and be thrown out within minutes.
I remoted in and noticed he had the wrong date on the laptop. What was happening was the log in set a cookie with an expiry but the date was such that the expiry date was before the date on the laptop and he was thrown out.
I was well chuffed.
*He rang years and years ago asking how to delete his browsing history but as a Compuserve (remeber them) subscriber there was a duplicate history, which his 12 year old son found telling him oh if you wanted to delete your history you should have asked me.
What this article doesn't reveal is "how" the file got named credentials.txt.txt. Did the Yank open the file in notepad, and then save it without selecting "Show all files"? Or did our intrepid Limey create the file and save it without selecting "Show all files"?
On another note, as someone who had spent the last 21 years on the other side of this same arrangement, there has been many, many times when we have had to respond to our UK counterparts with "Why the %$#^ &^$%^* would we want to do THAT!"
Thankfully we now have our own Rob (really that's his name) on the right side of the pond who is our protector from the stupidity that comes from the revolving door of UK IT management.
Way back, way before I had a job I enjoy in Computing, I did a lot of work with Spreadsheets. Particularly one workbook with a dozen or so spreadsheets connected by a series of very complicated links that all updated each other. I had a low end 286 based PC that did struggle to update this sheet. It actually struggled to do much once Windows 3.1 started..
This workbook was important because once a month, it went to finance and they used it to charge other departments for our service. As such, it was our only source of income.
My boss didn't have (or need) a PC, but their boss had a then state of the art 486 DX2 66 that ran Windows 3.1, Excel and this spreadsheet *easily*. As far as I could tell, all he used this PC for was reading the book I submitted. He had a PA with her own PC (that had a similar spec to his) for everything else he needed, which was primarily typing.
She, clearly frustrated with the Dos 8.3 naming convention, came up with a system for naming her files.. He files were all on floppy, in a neat box on her desk. Each disk was numbered, as was each file on it. She had a master floppy that just contained a text file listing all the file numbers, with the disk they were on and a detailed description of the file contents. She had no backups
Because I had a keen interest in computing, even then, and our IT support "team" was a single tech support person for several hundred staff, I got roped into supporting the entire department.
I think you can probably guess where this is going. I got a call from the PA one day to say her PC wasn't opening a file. When I went and had a look, the file that had corrupted was this index file, and the disk itself had been damaged, rendering the contents unreadable.
I did try a few utilities (this was back when Norton Utilities was a good thing), but failed to get much of the data back. I copied what I could to a new disk, and she had to go through every file on every other disk, re-creating what she had. There were over 500 files. She made sure to take backups after that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
