Not A System Problem [LWN.net]

Not A System Problem

Posted Mar 26, 2009 9:56 UTC (Thu) by ldo (guest, #40946)
Parent article: Wheeler: Fixing Unix/Linux/POSIX Filenames

I dont think there should be any limitations on filenames at all. Even the usual Unix/POSIX prohibition against slash and null should go. The only problems happen with userspace languages and APIs that do interpretation of special characters when youre trying to pass them a pathname, therefore all such languages/APIs should be fixed to provide ways of bypassing such interpretations, perhaps by an escape syntax. Thats the right way to solve things.

to post comments

Not A System Problem

Posted Mar 27, 2009 0:56 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

Um, if you remove the prohibition on nulls, how do you end the filename?
This isn't Pascal.

And if you remove the prohibition on slashes, how do you distinguish
between a file called foo/bar and a file called bar in a subdirectory foo?

These limitations are there because the semantics of the filesystem itself
depends on them.

Re: Not A System Problem

Posted Mar 29, 2009 10:30 UTC (Sun) by ldo (guest, #40946) [Link] (3 responses)

nix wrote:

Um, if you remove the prohibition on nulls, how do you end the filename? This isn't Pascal.

Nothing to do with Pascal. C is perfectly capable of dealing with arbitrary data bytes, otherwise large parts of both kernel and userland code wouldnt work.

And if you remove the prohibition on slashes, how do you distinguish between a file called foo/bar and a file called bar in a subdirectory foo?

Simple. The kernel-level filesystem calls will not take a full pathname. Instead, they will take a parent directory ID and the name of an item within that directory. Other OSes, like VMS and old MacOS, were doing this sort of thing decades ago.

Full pathname parsing becomes a function of the userland runtime. The kernel no longer cares what the pathname separator, or even what the pathname syntax, might be.

Re: Not A System Problem

Posted Mar 29, 2009 13:54 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

What you're describing is not POSIX anymore. Every single POSIX app would
need rewriting, for essentially zero gain (ooh, you can't have nulls in
filenames: that's why UTF-8 is *defined* to avoid nulls in filenames).

I'm sure users would love not being able to type in pathnames anymore,
too.

Good luck getting anyone to do it.

Re: Not A System Problem

Posted Mar 29, 2009 19:47 UTC (Sun) by ldo (guest, #40946) [Link] (1 responses)

nix wrote:

What you're describing is not POSIX anymore.

Nothing to do with POSIX. POSIX is a userland API, it doesnt dictate how the kernel should work.

Re: Not A System Problem

Posted Mar 29, 2009 22:32 UTC (Sun) by nix (subscriber, #2304) [Link]

You don't get it. In order to permit / and \0 as valid filename
characters, syscalls like open() must change. Library calls like fopen()
have to change, because they too accept a \0-terminated string, with /s
separating path components. Every single call in every library that
accepts pathnames has to change. Probably the very notion of a string has
to change to something non-\0-terminated.

So whatever you're describing, userspace cannot any longer use standard
POSIX calls: in fact, it can't any longer use ANSI C calls! I suspect that
such a system would be almost unusable with C, simply because you couldn't
use C string literals for anything.

If you want VMS, you know where to find it.