Re: [Bug-tar] mac os x or general charset problem patch

[Heiko Voigt]

Quoting Joerg Schilling <address@hidden>:

> Heiko Voigt <address@hidden> wrote:
> > Its the characters 'äöü' which are in the latin1 table at 228,246,252.
> > The filesystem is capable of these characters but it uses UTF-8 to
> > encode them. I use HFS+ and have no ufs formatted drives on hand, so I
> > can't test it at the moment.
>
> HFS+ is not POSIX compliant. POSIX requires a case sensitive filesystem.
> There may be more problems with HFS+

I did not claim that it is POSIX compliant.

> UTF-8 could only be the universal solution if there would be no other codings
> out in the world.....
>
> Creating a filesystem with fixed character encoding creates problems in a
> multi user system (like UNIX) where each process may use it's own different
> coding. This is why filesystems usually allow any non-null character in
> path names and why UTF-8 has been defined in a way that makes sure that
> no character > 127 uses a '/' inside any octet of it's coding.

As I read from the standard a POSIX system only has to support the portable
characterset. This is again of course not fully supported by HFS+ because of
the case insensitivity but this characterset only consists of the 127 ASCII
characters.

It says: "The encoded values associated with the members of the portable
character set are each represented in a single byte. Moreover, if the value is
stored in an object of C-language type char, it is guaranteed to be positive
(except the NUL, which is always zero)."
http://www.unix.org/single_unix_specification/

So thats what shall be supported and so for me it does make sense to introduce
some option for tar which translates characters from outside this coding to the
portable coding.

bye Heiko