Re: RFC: Illegal Characters in File Names

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]

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 contrast
> > with EBCDIC, koi8, iso 9036, big5, iso 2022, iso 2033, iso 5427, etc.
> 
> 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).
> 
> 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 steps.
> 
> 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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]