Earlier quoted context omitted.
It's some sort of bug around saving "non-standard" extensions. And it seems to grab as many of the original characters as it can that match a known extension, so `test.foo` becomes `test.foo.f`, `test.solo` becomes `test.solo.s`, but `test.executive` becomes `test.executive.exe`, and `test.asm` becomes `test.as` And it affects their code that they run to validate when you change an extension. Normally if you open a f…
But this isn't DOS with a hardcoded 8.3 filename. You can have any number of dots in a filename on a Unix-style OS, and there's nothing special about whatever follows the final one. What you think of as file extensions are merely a matter of convention. Some applications may treat them more seriously, but that should be up to the app to enforce - not the OS. I can see no reason why a system-wide file dialog should ev…
Re: Sublime text started adding a “.s” to new files
#131I think this is a combination of a bug interacting with two different things. One is the extension change checker, and the other is the system that adds extensions invisibly in order that the OS can still pretend 23 years later that extensions don't matter. Because while you're right about the fact that extensions shouldn't matter, you're wrong about the fact that they do. Because unlike classic mac os, we don't have file types encoded in the metadata of the file anymore. The only way for an application to specify the types of files it can or can't handle is the extension. And likewise for telling the OS which applications should open a given file type by default. The extension does matter, because it's important metadata the OS and applications use to determine how to handle the file. macOS tries to hide this importance by default and won't show extensions if you don't want it to. But in order for that to work and for files to still be the right type so other apps can know what to do with them, the OS save dialog MUST put a proper extension on the file, even if you don't display it. But now because that's something that can (and will) be changed in the save dialog, it also has to check if you're applying a new extension to a file that already has an extension. Because it needs to confirm if you meant to change the extension or just (as you point out is possible) add another dot separation to the file name. So there's probably a bug in the part that's supposed to be checking for whether it needs to add the extension. Some default case path got broken, and it's taking the case where you save, but include an extension as being saved without an extension because it didn't recognize the extension from its list of "proper" extensions.