In article , Wolf K
wrote:

On 2017-12-14 10:18, nospam wrote:
In article , Tim Streater
wrote:

| The type of a file and which app you'd like it to open with are
| items
| of file metadata and have no business being part of the filename.

| Many files have such type-identifiers included. E.g., a JPG file
| begins
| with JFIF, a WordPerfect file includes WPC in the first line, an MS
| .doc

| Then you've put the metadata inside the file, which is even worse. It
| should be part of the file system.

This is the problem with mixing Mac and Windows
discussions. As I understand it, Mac stores file data
separately as a "resource fork".

No, you have it back to front. File data went in the data fork,
metadata went in the resource fork.

no it didn't.

metadata was kept in the file system.

the resource fork (which was optional, as was the data fork) held
various resources. it was basically a miniature database.

a zero-length file would have an empty data *and* resource fork. rare,
but possible.

Unfortunately Apple has abandoned
this idea and settled for the lowest-common-denominator approach, and
w're all the worse off for it.

yep.

Educate me. What's the advantage of the "forks"? As described, it looks
like metadata with a fancy name, apparently conceived as attached to or
pointed to by the file. Presumably it's stored separately from the file.

Resource Forks are completely unrelated to metadata.

The 2-fork architecture was inherited from Classic Mac OS, and, while
still supported by mac OS X, it is used much less frequently.

In Classic Mac OS, every file consisted of two separate forks (either of
which could be empty).

The Resource Fork contained structured data which was managed by the
operating system which defined a wide variety of resource types (though
applications could define there own). These included GUI elements like
menu templates, window templates, dialog item lists, icons etc. as well
as things like fonts, device drivers, executable code segments, keyboard
layouts etc.

The data fork contained anything the application which created the file
wanted to put there and the application was responsible for interpreting
and organizaing that data.

Metadata wasn't stored in either fork. It was stored in the desktop
database which was maintained by the finder.

The advantage of the resource fork was simply that it made the mac much
easier to program since datatypes used by the OS were entirely managed
by the OS rather than the application (and it made it easier to
customize the GUI of existing applications).

The majority of files which one would actually want to distribute
cross-platform would have only a data fork as files which made use of
the resource fork were generally mac-only files anyways. The bigger
problem back in the day was transferring mac files to another mac across
another system (Windows, *nix, etc.) which didn't recognize the resource
fork.

Andre

--
To email remove 'invalid' & replace 'gm' with well known Google mail service.