Finder on macOS does this too. It's maddening...
There was an article recently about "hostile architecture" and this is similarly a "hostile software design" to prevent users from doing something the developers don't want them to do.
There was an article recently about "hostile architecture" and this is similarly a "hostile software design" to prevent users from doing something the developers don't want them to do.
shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource fork, but designed to be ephemeral) are a much more sane solution.
At this point, it might as well be a "resource fork" or whatever you want to call your secondary file contents at the fs layer shrug
The only real reason i care is for vim file detection (in Linux). How sad is that? :'(
APFS has good extended attribute support. Whereas linux extended attributes might be limited to 64k, APFS extended attributes can be significantly bigger (I just created a 32MB one).
The xnu kernel has some ugly hacks (pre-dating APFS) which make the "com.apple.ResourceFork" available as a file ("/..namedfork/rsrc").
On HFS/HFS+, file/..namedfork/rsrc will always exist (and usually be empty). on APFS, file/..namedfork/rsrc will generate an ENOENT error if the resource fork/attribute doesn't exist.
Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked.
It was impossible for the user to change either (in the stock OS).
That's... much, much worse than dot extensions.
The type codes were editable, in the sense you could choose the default app you wanted to open files of that type, which is really what you'd want to modify most of the time.
BTW, I think you're referring to the 'creator' code, not the 'type' code. The 'creator' code determined which application would open a file when it was opened. And it was per-file; I don't remember any mention of a system-wide 'default application' or anything like that.
This was actually rather nice in practice. It meant a JPEG image created by e.g., GraphicsConverter would be opened by GraphicsConverter when double-clicked; whereas one saved by a web browser would be opened in the web browser. But either could be dragged into either application in order to open the web-browser-saved image with GraphicsConverter.
The Finder maintained a 'desktop database' which, I believe, was used by the operating system to determine which Applications were able to open files given their type. This was updated automagically, so given a floppy disk with an application on it, and a file that could be opened by that application, the user could insert the disk, double-click the file and the application would be launched to open the file--even if the application was previously unknown to the machine in question.
Power users could use ResEdit or some other tool to change such attributes of a file.
http://vintagemacmuseum.com/macintosh-type-and-creator-codes... has some more info about the system. Also https://tidbits.com/2009/09/06/snow-leopard-snubs-document-c... which remarks on the system's retirement in OS X 10.6.
Reminiscing about all this makes me remember fondly how much better the experience of using a Mac back in the 90s was compared to computing nowadays!
I find it amazing that despite the industry's trend in recent years away from string-typing and towards static-typing, metadata-in-file-name just won't die.
I'm all for removing old ways of doing things that were bad, when we have a better way to do them. What we have here, with type-in-extension (and visibility-in-prefix), is a legacy system for which there is so far no workable substitute (on any system, much less all systems). A person can't be fully computer literate and not know what extensions are.
UTI has some nice features, but it's still based on extensions (which are keys into the database with the information you really want). This weird halfway point, where every user has to be a "power user" of the filesystem in order to not break their own files, will live on until either types are made primary again, or until we're all reduced to using standalone "apps" with app-specific storage and we can't share any data except as the app author decided to allow.
That's fine, not every task that is possible must be directly supported by the OS - third party apps to fiddle with data that is considered non-primary workflow like that is OK.