Quoting Joerg Schilling <[EMAIL PROTECTED]>: > Heiko Voigt <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
