Re: wide characters and i18n

[Giles Lean <giles.lean%pobox.com@localhost>]

markucz%gmail.com@localhost wrote:

> How about (user settable) extended attributes? It's a nice way to handle
> meta-data and is useful if you want ACLs. Besides, extended attributes are
> natively supported by UFS2.

Introduces fascinating (er, frustrating?) portability issues, and the
old debate about whether meta data (and resource forks and the like)
should merely be replaced but the idea of using a directory and putting
all the extra stuff in it as extra files.

Note that it took Apple quite a long time to get all (assuming it's now
"all") of the file handling/copying/archiving utilities to support
HFS+'s extended attributes and ACLs, and they can't make up their
minds whether they really want to deprecate resource forks or not.

Then after adding support you have to get it right: I have a HFS+
file system which Apple's rsync will not ever say is synchronised,
despite all files having the same size, length, checksum(!), ACLs,
extended attributes, and ownership.   Maybe that bug's fixed in
Snow Leopard (the current OS X release at the time of writing) and
maybe it's not too.

It's a hard problem.  For binary format files I personally think
magic numbers remain a pretty good (workable, and robust if not
perfect) solution.

For "text" files (where this discussion began) where you want to know
the character set extended attributes _do_ start to make a claim: while
it might be arguable (as I did) that directories and multiple files are
theoretically equivalently powerful, we just are not accustomed to
thinking of a "directory" as a file, and similar softare changes are
needed in either case.

Giles