From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Hudec Subject: Re: RFC: Illegal Characters in File Names Date: Tue, 20 Jul 2004 10:45:20 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040720084520.GI3227@vagabond> References: <20040720024359.GB26892@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="54u2kuW9sGWg/X+X" Cc: 'Matthew Wilcox' , linux-fsdevel@vger.kernel.org Return-path: Received: from cimice4.lam.cz ([212.71.168.94]:8355 "EHLO vagabond.light.src") by vger.kernel.org with ESMTP id S265743AbUGTIpY (ORCPT ); Tue, 20 Jul 2004 04:45:24 -0400 To: "Joseph D. Wagner" Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org --54u2kuW9sGWg/X+X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 19, 2004 at 22:16:22 -0500, Joseph D. Wagner wrote: > > utf8, ascii and iso8859 are not the only encodings. Compare and contra= st > > with EBCDIC, koi8, iso 9036, big5, iso 2022, iso 2033, iso 5427, etc. >=20 > Same thing. These encoding mechanisms preserve the lower 128 of ASCII. = There shouldn't be a problem. Read the list again, please. Ebcdic is included there. > > There's nothing to stop people encoding filenames in something like a > > carefully selected subset of ucs2 (to avoid 0x00 and 0x3a bytes). >=20 > Isn't that the problem? No. It's not a problem. The filesystem does not need to care -- thus it shouldn't. > A lack of standardization? I'm thinking of the future of Linux here. > Isn't it easier for application developer's everywhere if there was > some uniformity to the encoding mechanism? Writing applications is easier when encoding is uniform. That's why Gtk2 enforces utf-8 internaly and why tcl and python only use utf-8 internaly and so on and so on. Still the kernel shouldn't care. It's userland's business. > But like I said, that's too much to address at once. Gotta think baby st= eps. >=20 > Back to the topic, can you think of a GOOD reason that non-printing > control characters in the lower 128 SHOULD be allowed? I'm drawing > a blank. Hence, shouldn't we change it to disallow those characters? Things should be disallowed if there is a good reason to disallow them. If there is not, they should be allowed. It would add extraneous complexity to disallow them. The filesystem code has no problem with those characters, so it should not enforce arbitrary restrictions on them. Those who have problems should enforce solutions. ---------------------------------------------------------------------------= ---- Jan 'Bulb' Hudec --54u2kuW9sGWg/X+X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/NugRel1vVwhjGURAvu6AJ0Sg5/C17ObRNstGL0fxorBE2awMQCg75Dy S5HnVqMUrR0USKueo515JYo= =Nt+J -----END PGP SIGNATURE----- --54u2kuW9sGWg/X+X--