From owner-freebsd-hackers Thu Aug 27 15:49:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19726 for freebsd-hackers-outgoing; Thu, 27 Aug 1998 15:49:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rrz.Hanse.DE (rrz.Hanse.DE [193.174.9.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19709 for ; Thu, 27 Aug 1998 15:49:19 -0700 (PDT) (envelope-from stb@hanse.de) Received: from daemon.Hanse.DE (daemon.Hanse.DE [193.174.9.17]) by rrz.Hanse.DE (8.8.8/8.8.8) with ESMTP id XAA21242; Thu, 27 Aug 1998 23:55:53 +0200 (CEST) (envelope-from stb@hanse.de) Received: from transit.hanse.de (transit.Hanse.DE [193.174.9.161]) by daemon.Hanse.DE (8.8.8/8.8.8) with ESMTP id AAA03676; Fri, 28 Aug 1998 00:49:28 +0200 (CEST) (envelope-from stb@hanse.de) Received: from localhost (stb@localhost) by transit.hanse.de (8.8.8/8.8.8) with SMTP id AAA27314; Fri, 28 Aug 1998 00:48:11 +0200 (CEST) X-Authentication-Warning: transit.hanse.de: stb owned process doing -bs Date: Fri, 28 Aug 1998 00:48:10 +0200 (CEST) From: Stefan Bethke To: Terry Lambert cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Warning: Change to netatalk's file name handling In-Reply-To: <199808272220.PAA28457@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 Hamburg, Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message