A day or so ago, I was reminded of one of Apple’s stupidest actions ever, one that has left everything running macOS open to a DOS attack, a thing that no only will they refuse to fix, but one they defend, because it only affects user data, so an app that would rampantly mess up your ability to use files without deleting or harming them at all, but by modifying one piece of file metadata, make it hard, if not impossible to correctly use that file.
The post:
And this is why you don’t use file name metadata as your sole determinant for what a file is, does, or belongs to.
My post on mastodon
<stares at macOS where a script/app that yanked all the file name extensions from every file in your home directory would be a (sadly) extremely effective way to DOS you on your own computer because without filename, UTIs fail to work and the OS (and every app that didn’t exist prior to OS X) will not only not know what to fucking do with the file…>
It was a sort of quote tweet of another post by someone else talking about how having TLDs that end in .mov or .zip could be a bad idea. I don’t completely agree, we’ve had .com for a long time, but, to be fair, the days of actually using .com executables as a common thing are somewhat in the past.
However, it did remind me of how unless the dev takes steps to prevent it, if I want to force you to do a lot of work, like file restores, all I have to do is embed a…between 1 and 3-line script in an application that has a good reason to get access to things like your documents directory, your iCloud directory, OneDrive directory and similar, (not hard do do for any document-based application) and all that script has to do is delete all filename extensions from every file it can find, and well, unless you know what’s up, you’re…what’s the phrase…oh, right:
You’re Fucked
Now, if you have a decent backup/archiving system, and you can just completely restore all the contents of those directories, well, it’s still a lot of tedium, especially if you use cloud backups and aren’t in a location with lots of bandwidth, but at least then it’s fixable.
However, if you are not, or your backup strategy has…holes…then thanks to Apple’s complete reliance on file metadata, the filename extension, you have little chance of getting your files back to normal anytime soon. Here, a tour:
So here we have a pages file, it’s a homework file for a class I’m taking. If I want to get details reasonably easy, a bit of fun with AppleScript’s “info for” command and here’s what Script Debugger has for us:
That looks normal. We see the file name, with the extension (.pages), the kind is a “Pages Document”, and the UTI is “com.apple.iwork.pages.sffpages.” If we double-click on the file, it opens in Pages. If we use File -> Open in Pages, we can open the file. If we right-click the file and select “Open”, it opens in Pages. If we right-click the file and select “Open With”, Pages is the default. All is as it should be, right down to the icon in the Get Info Window:
All Is Well
But
What happens if we change the file name, specifically, if we remove the Pages extension?
Fail
First, the file icon changes to a generic Unix Command line utility icon. No, really:
Same file, only thing that changed was part of the file name. Just happened to be the “wrong” part. But surely, that’s not correct for everything, surely the OS still knows what kind of file it is…
Um…nope:
Pages won’t open it at all:
Gotta say that circled part is my favorite thing ever. And no, “Open With” doesn’t work. Unless you happen to know what that file is in terms of the “proper” file name extension, or can restore an earlier version, congrats, that file is lost to you. Even if you try to look at the raw elements of the file in say, BBEdit, which will show you the file structure:
The files in the metadata folder? Nope. Here’s what they have:
BuildVersionHistory.plist
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<array>
<string>Template: Blank (12.1)</string>
<string>M12.2.1-7035.0.161-2</string>
</array>
</plist>
DocumentIdentifier.plist:
EE9FEC88-81E3-4BA8-AA2E-C51C5E429CD8
Properties.plist
The only chance you have is the preview.jpg file, which shows you a preview of the first page of the document. That’s it. all the .iwa files are snappy-compressed files, and of course, the Archive Utility won’t touch them. BRILLIANT.
Now, it’s not just Apple mind you. Most what old-timers would call Cocoa apps have the same problem. Here, Pixelmator Pro.
File with extension:
Same file, no extension:
(If you try to open it with TextEdit, it does not work)
What happens if you try “Open With” and force Pixelmator Pro to try? Well…
So that’s a fail. Look, I’m not really bagging on the Pixelmator folks right? They’re doing what Apple recommends. The problem is, this isn’t i(Pad)OS where there’s other ways to manage this and I can’t just arbitrarily mung the filename like this. At least with Pixelmator, if you open the file in BBEdit, the metadata.info file is a SQLite database file with the application name in there, so at least theoretically, if you know how to troll through SQLite files and you know what you’re looking for, you have a chance to fix it. iWork files (or really any file from Apple), lol, you’re screwed.
Oh and if you use the default view in the Finder, that hides file extensions? you can’t even tell the name was changed! 
The only visual indication is the icon. But that’s not the most egregious example. Wonder what happens if you yank the extension off a Shortcuts file? Of course you do, you’ve read this far, WHY STOP THE AGONY NOW?
Just by removing the extension, POOF! IT’S A FOLDER.
By the way, to all you nerds who love to laugh at people who think you can make a jpeg into Word doc just by changing the filename extension? CRAP LIKE THIS IS WHY! PUSHING AND ADVOCATING FOR THIS SHIT IS WHY THAT HAPPENS! IT’S YOUR FAULT, 100%
But surely there’s an application that isn’t stupid. Why yes, yes there is. My favorite example, MICROSOFT WORD.
With the filename extension:
All as expected. But now, let us remove the extension…
okay, that’s expected, a generic icon. At least it’s a document icon, and not a unix executable or a gods-damned folder.
See, just like…wait, it’s still a Word file, even without an extension. That can’t be right…
But it is right. And the reason, for the youngin’s out there isn’t obvious, so let me explain.
If you look at the file info for either word version, you’re going to see two values that don’t exist for pages/shortcuts/pixelmator pro/”new” application files: file creator and file type. Back in the before (OS X/macOS) times, on a Mac, the filename extension truly was metadata. It was mostly there for sharing files with other platforms, like Windows that heavily relied on the filename extension. But the older Mac OS, didn’t care, because of those two values. If you hear old-timers talking about resource forks, that’s a lot of what they did: they told the OS and the Finder what kind of file a thing was. Wasn’t just for document files either:
No need for .exe or .app or what have you. Just a bit of metadata that existed outside of what you saw, so changing the name and/or filesystem didn’t change a file into a folder or even appear to.
Now, the implementation of this in the Classic Mac OS was anything but perfect. It created its own brand of magical thinking, i.e. “Rebuild the Desktop” was the classic version of “Repair Permissions”, but it was a way to ensure a file was what you thought it was regardless of name, and clearly it still works. It’s not the best thing right, I mean, prior to the Office XML files, the file type was “WDBN” and I think at one point, there was a “WD4N” or something. Having only four characters meant things got weird, but the concept of file types that aren’t solely reliant on something as trivially changed as the file name makes a lot of sense, and prevents the kind of DOS attack that every copy of macOS is pathetically vulnerable to.
Oh, and please, Office people, CC people, really, anyone who’s been building apps since before OS X, please keep using File Types and Creator Codes. I know it’s a pain in the ass, I really do, but the few times you need them, you need them and they will literally save your ass. Thank you for that extra work, it’s a genuine help, and we appreciate it.
Before the pedants feel the need to bother me with it, if I render someone unable to actually use their computer, to work on their files until they do a massive document restore, probably multiples given the defaults not showing you the extensions so you can’t even see the problem until you try to open your folder, I mean file, that is a Denial of Service attack. It is denying you the ability to use your computer and your files, it is most definitely a DOS attack. Or DoS for the overly case-sensitive.
Just because the OS and the Applications can sit there and quietly navel-gaze doesn’t mean there’s no problem. At that point, the difference between hundreds/thousands of files you can’t use and an erased hard drive is not as great as you wish to think, especially for folks who are not coders, are not sysadmins and just want to use their computer to do work, to get through a class, to write stories or make paintings or all the things computers are used for that aren’t sysadmin or coding. I know it’s shocking, but non-tech workers do “real” work too. Some of you may need some time to internalize that, but it needs to be done.
The sad thing, the absolutely sad thing is there’s a fix that’s almost trivial: let applications set UTIs within file EAs instead of deriving them from the filename or making people try to use file types and creator codes. Most of the work is already done, applications can set the UTIs they use/conform to, you can still associate UTIs with filename extensions/MIME types (which you’d need to do for files coming from non-Apple OS’s), none of that has to go away, nor should it. But give the app creating the file the ability to write the pertinent type identifier into the file, and not just have it derived from something so trivially changed. Hell, make it read/write in Standard Additions so people can automate changing it for specific files en masse outside of the somewhat kludgy “Get Info” window.
Adding this capability would cause effectively zero harm and remove a vector to cause harm, or at least make it harder to do that. All the mechanisms are in place, it would be a trivial API change, and no, unlike one fine young dingus claimed the last time I talked about this, it would not keep you from having your web browser be the default for JPEGs you wee dork. It would just mean that if your file lost the .jpg/.jpeg extension, your web browser would still know it’s a goddamned JPEG. Nerds are the worst people to move anything forward for anyone but themselves, STG, SMDH.
But this won’t happen, because the powers that be at Apple and everyone else think doing an entire home directory restore from the cloud is trivial because it’s not like anyone ever doesn’t have 1G bandwidth at their fingertips.
S I G H
Like so many other things, Apple can improve this, they just neither care nor want to. Pity.
Bynkiidotcom 