5 ms·

You wouldn't put the entire content of a file in an extended attribute, would you?

granos 11y ago
Is that a problem with the fs and its features/implementation or a problem with how some application/developer chose to use those features?
rbanffy 11y ago
Fonts, when part of a program, were stored in a "FONT" fork (conversely, icons went into "ICON"). It's natural that font files would have nothing in the data fork and the font definition itself would be under FONT. Full documentation is available at https://developer.apple.com/legacy/library/documentation/mac/pdf/ResEditReference.pdf https://developer.apple.com/legacy/library/documentation/mac...
rogerbinns 11y ago
There are various arbitrary restrictions in various filesystems and operating systems. The intention is to store smaller amounts of useful information with the file. Smaller means in the bytes/kilobytes range. For example you wouldn't store multi-gigabyte alternate language versions of a video file in its extended attributes. But you could store URLs of where to get them. Or you could attach authorship, review, dates, keywords and similar metadata which would work for any file type, not just those whose format explicitly has that support. If you want to get a handle on what filesystem design is like then I highly recommend Dominic Giampaolo's book on the design and implementation of the Be filesystem (he wrote BeFS). The book is freely available from his website as http://www.nobius.org/~dbg/practical-file-system-design.pdf http://www.nobius.org/~dbg/practical-file-system-design.pdf and includes information about the design of other filesystems too. It isn't exhaustive, but does give a very good grounding in filesystems and does cover extended attributes.
- stefantalpalaru 11y ago
  Thanks for the recommendation, that book looks interesting.
blakeyrat 11y ago
On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type. So why wouldn't a stand-alone font file consist of a Resource fork with a single resource of "FONT" type? Otherwise, the OS engineers have to develop two entirely different ways of reading in font data. Why duplicate the effort? The system made perfect sense, both then and now. It bothers me that so few people know anything about Mac Classic, it really was an amazingly well-designed OS for its time.
- stefantalpalaru 11y ago
  It does not strike me as a sane design. You already have file extensions, unique prefixes (like those used by the 'file' command to identify files). Why would you use fs forks to differentiate between file types?
  - ascorbic 11y ago
    Mac OS Classic had no file extensions. I remember they felt like such a hack when switching to OS X, compared to the flexibility of resource forks.
  - amyjess 11y ago
    Actually, Classic Mac OS used type and creator codes, which were attributes on files, to identify filetypes, not resources.
    - stefantalpalaru 11y ago
      That makes more sense.
- mappu 11y ago
  >On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type. On Windows you can do the same thing with .rsrc in an .exe/.dll file. It's possible you would ship a font as a PE .dll with a font resource, but for a single file the encapsulation is a little unnecessary (unless your application architecture already makes it easy to deal with PE encapsulation).
amyjess 11y ago
In Classic Mac OS, most executables consisted entirely of resource forks. Even the code was stored in resources of type CODE.
- pvg 11y ago
  PowerPC executables stored code in the data fork.
  - amyjess 11y ago
    Ah, good to know. My last Mac was m68k (Performa 630CD, one of the very last m68k models), so my memories include seeing plenty of CODE resources when playing around with ResEdit.
    - pvg 11y ago
      Oh they stuck around, of course, an entire other chapter of historical MacOS zaniness in which many programs and the OS itself contained and ran both 68k and PPC code at the same time, there were 'universal procedure pointers', 'accelerated' CODE resources (with PPC code in them) and on and on.
mdellabitta 11y ago
Actually, I believe OS X does this for small files in order to not burn a whole filesystem block on a sub 1k file. "In Mac OS X Snow Leopard 10.6, HFS+ compression was added. In open source and some other areas this is referred to as AppleFSCompression. Compressed data may be stored in either an extended attribute or the resource fork.[13] When using non-Apple APIs, AppleFSCompression is not always completely transparent." https://en.wikipedia.org/wiki/HFS_Plus#History https://en.wikipedia.org/wiki/HFS_Plus#History
- astrange 11y ago
  FS compression is transparent to any regular file-reading API; it only shows up in lower-level APIs, like if you want to copy the file and keep the compression.
  - mdellabitta 11y ago
    I was responding to the comment "You wouldn't put the entire content of a file in an extended attribute, would you?" HFS+ does, although in this case, it does without leaking that detail to callers.

Is that a problem with the fs and its features/implementation or a problem with how some application/developer chose to use those features?

rbanffy 11y ago

Fonts, when part of a program, were stored in a "FONT" fork (conversely, icons went into "ICON"). It's natural that font files would have nothing in the data fork and the font definition itself would be under FONT. Full documentation is available at https://developer.apple.com/legacy/library/documentation/mac/pdf/ResEditReference.pdf https://developer.apple.com/legacy/library/documentation/mac...

rogerbinns 11y ago

There are various arbitrary restrictions in various filesystems and operating systems. The intention is to store smaller amounts of useful information with the file. Smaller means in the bytes/kilobytes range. For example you wouldn't store multi-gigabyte alternate language versions of a video file in its extended attributes. But you could store URLs of where to get them. Or you could attach authorship, review, dates, keywords and similar metadata which would work for any file type, not just those whose format explicitly has that support. If you want to get a handle on what filesystem design is like then I highly recommend Dominic Giampaolo's book on the design and implementation of the Be filesystem (he wrote BeFS). The book is freely available from his website as http://www.nobius.org/~dbg/practical-file-system-design.pdf http://www.nobius.org/~dbg/practical-file-system-design.pdf and includes information about the design of other filesystems too. It isn't exhaustive, but does give a very good grounding in filesystems and does cover extended attributes.

stefantalpalaru 11y ago
Thanks for the recommendation, that book looks interesting.

blakeyrat 11y ago

On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type. So why wouldn't a stand-alone font file consist of a Resource fork with a single resource of "FONT" type? Otherwise, the OS engineers have to develop two entirely different ways of reading in font data. Why duplicate the effort? The system made perfect sense, both then and now. It bothers me that so few people know anything about Mac Classic, it really was an amazingly well-designed OS for its time.

stefantalpalaru 11y ago
It does not strike me as a sane design. You already have file extensions, unique prefixes (like those used by the 'file' command to identify files). Why would you use fs forks to differentiate between file types?
- ascorbic 11y ago
  Mac OS Classic had no file extensions. I remember they felt like such a hack when switching to OS X, compared to the flexibility of resource forks.
- amyjess 11y ago
  Actually, Classic Mac OS used type and creator codes, which were attributes on files, to identify filetypes, not resources.
  - stefantalpalaru 11y ago
    That makes more sense.
mappu 11y ago
>On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type. On Windows you can do the same thing with .rsrc in an .exe/.dll file. It's possible you would ship a font as a PE .dll with a font resource, but for a single file the encapsulation is a little unnecessary (unless your application architecture already makes it easy to deal with PE encapsulation).

amyjess 11y ago

In Classic Mac OS, most executables consisted entirely of resource forks. Even the code was stored in resources of type CODE.

pvg 11y ago
PowerPC executables stored code in the data fork.
- amyjess 11y ago
  Ah, good to know. My last Mac was m68k (Performa 630CD, one of the very last m68k models), so my memories include seeing plenty of CODE resources when playing around with ResEdit.
  - pvg 11y ago
    Oh they stuck around, of course, an entire other chapter of historical MacOS zaniness in which many programs and the OS itself contained and ran both 68k and PPC code at the same time, there were 'universal procedure pointers', 'accelerated' CODE resources (with PPC code in them) and on and on.

mdellabitta 11y ago

Actually, I believe OS X does this for small files in order to not burn a whole filesystem block on a sub 1k file. "In Mac OS X Snow Leopard 10.6, HFS+ compression was added. In open source and some other areas this is referred to as AppleFSCompression. Compressed data may be stored in either an extended attribute or the resource fork.[13] When using non-Apple APIs, AppleFSCompression is not always completely transparent." https://en.wikipedia.org/wiki/HFS_Plus#History https://en.wikipedia.org/wiki/HFS_Plus#History

astrange 11y ago
FS compression is transparent to any regular file-reading API; it only shows up in lower-level APIs, like if you want to copy the file and keep the compression.
- mdellabitta 11y ago
  I was responding to the comment "You wouldn't put the entire content of a file in an extended attribute, would you?" HFS+ does, although in this case, it does without leaking that detail to callers.