Date: Fri, 28 Aug 1998 00:48:10 +0200 (CEST) From: Stefan Bethke <stb@hanse.de> To: Terry Lambert <tlambert@primenet.com> Cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Warning: Change to netatalk's file name handling Message-ID: <Pine.BSF.3.96.980828003723.24324D-100000@transit.hanse.de> In-Reply-To: <199808272220.PAA28457@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Aug 1998, Terry Lambert wrote: > > AFAIK, there is no character set or encoding defined for file names in > > FreeBSD, in UNIX, or in POSIX. The only implicit definition is plain ASCII. > > Actually, the definition is "8 bit clean, 0x00-0x7f US ASCII"; this is > sufficient for ISO 8859-X, Shift-JIS, EUC-JP, BIG5, EUC-TW, GB, EUC-R, > ISO-2022-KR, and KOI8-R representations. Yes. The questions isn't whether UFS allows for filenames with byte values in the range 0x01 to 0xFF, but rather how to interpret them. > > Even if we were to translate from the Mac enconding to (say) ISO-8859-1, > > this would loose some of the chars legal in Mac filenames, causing grief to > > the typical unsuspecting graphics designer. > > Or you could just leave it alone, as 8-bit clean, and allow the > existing ISO 2022 character set selection mechanisms in wide use to > continue functiong normally. I'm not particular aquainted with ISO 2022, so I don't really get what this would buy me in terms of interoperability of existing apps. > > So we need afpd to confine to ASCII, and, as I would suggest, to printable > > ASCII, as this will make most peoples' live easier (for ASCII, byte values > > from \0x00 to \0x1F and \0x7F do not produce a glyph, so it is practically > > useless to store them as-is). > > You can not store 0x00 in the UNIX namespace. > > I believe this is a volume seperator in HFS; it can be replaces with > ":" in translation. > > Specifically, there are exactly two characters you can not use in-band > in the HPFS namespace, and exactly two characters you can not use in > the FFS namespace (0x00 and "/"), and the translation is natural and > obvious. The current escape mechanism apfd uses escapes "/" and 0x80 to 0xFF. I propose to change this to "/", 0x01 to 0x1F and 0x7F to 0xFF. The escape mechanism map the sequence ":xx" to each of the escaped codes. Because ":" is illegal in AFP filenames (its the path seperator), the reverse operation is indeed natural. > > > [ On the InterJet, for example, you can have it set to Japanese mode, > > > and shared files appear with the same name under AppleTalk and > > > Windows, ie, Samba and Netatalk use the same character encoding. ] > > > > That is definitly cool. I hope Julian can provide me with either the > > patches or the contact, so I can (at least) evaluate and turn down the > > patches :-) > > Jeremy Allison of the SAMBA team did the code. Contact him directly > at SGI. Jeremy seems to have switched addresses. Julian was kind enought to send me the patches; however, I don't feel to add code page support to netatalk. Stefan -- Stefan Bethke Muehlendamm 12 Phone: +49-40-256848, +49-177-3504009 D-22087 Hamburg <stefan.bethke@hanse.de> Hamburg, Germany <stb@freebsd.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980828003723.24324D-100000>