Heiko Voigt <[EMAIL PROTECTED]> wrote:
> > 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.
These are minimum POSIX requirements.
And to be complete, it seems that POSIX does not even require ASCII.
IBM's z/OS did get a UNIX brand permission and uses EBCDIC coding.
A system that allows people to work in today's world needs to support more and
a system that is prepared for a multi-user environment usually does not have
any restrictions on the file name except that it cannot contain null chars.
The main statement from POSIX is that iff the system uses ASCII based character
sets and iff it allows more than 7 bit ASCII, then the coding needs to be
agreed on and a conversion may be needed.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Bug-tar mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-tar
