|
|
|
|
|
|
by justizin
3855 days ago
|
|
|
I'm sorry, OP, but NTFS has resource forks as well, and they have value. The fonts are probably in resource forks because you are prohibited by copyright from copying or transferring them, but in other situations, they represent data that is only valuable to Mac OS, so that, say, if you rsync a bunch of files to a UNIX/Linux machine, you don't get things that are OSX-specific. That said, it is a fairly non-transparent and mysterious bit of functionality. My favorite thing about HFS+ is that about ten years ago at WWDC, I sat in with the Darwin Filesystem Birds-of-Feather, and asked them why it is case sensitive. They gave me a very simple answer: Microsoft Office.
Office, like basically apparently all Microsoft software, aggressively takes any filename string you give it and sends it through a rube-goldberg machine of forced uppercasing and lowercasing at several levels of the application, and therefore does not reliably open "Something.txt" as "something.txt" or "SOMETHING.TXT", but will absolutely never open "Something.txt".So, on my personal Macs, I actually run HFS+X, which is case sensitive and was designed for OSX Server. Homebrew works, all Apple apps and native Mac apps work. Office will almost definitely still not, but LibreOffice will. |
|
|
Although resource forks were just another data stream at the filesystem level, the OS treated them as structured data, with record types and IDs. They were used to store user interface elements--icons, pictures, window definitions, dialog boxes, etc.--as well as string lists, version information, and, yes, fonts. Even the executable was stored as a resource (M68k code that is; PowerPC binary was in the data fork). Applications could define their own resource types too.
As another poster points out, this scheme helped applications manage memory by only loading into RAM the resources it actually needed at any given time.