Re: [PATCH 3/3] read_directory(): infrastructure for pathname character set conversion

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 14, 2009, 21:23 UTC
Message-ID: <alpine.LFD.2.01.0905141413080.3343@localhost.localdomain>
In-Reply-To: <alpine.LFD.2.01.0905141346440.3343@localhost.localdomain>

On Thu, 14 May 2009, Linus Torvalds wrote:

> In particular, this allows:
> 
>  - the filesystem path component separator to be set to something
>    different than the normal UNIX '/' character.

I forgot to mention that this also now allows really having a different prefix. The old code had "path" and "base", and without really reading the code you might think that you could have a different base for the two, but immediately when it recursed, it would re-set the path and base to be the same thing, so you could never really have two different address spaces.

The new code very much intentionally keeps the two apart, and the _intention_ is that on platforms like Windows, you should not just be able to use other path component separators like '\', it should also be possible to use an absolute base (which, if I recall correctly, is the only way to handle things like long path-names. But maybe I'm wrong - I really don't know the crazy native Windows API's).

IOW, the _intention_ is that you could literally pass in something like

	"c:\Source\git\myrepo"

as the "path", and with an empty "base", it would then be possible to basically traverse the tree with the filesystem operations building up a "path" like

	c:\Source\git\myrepo\subdir\myfile.txt

while "base" would track it, but become "subdir/myfile.txt".

In fact, my intention was that the pathname could easily be in some crazy UTF16LE format (ie not a real "string" at all), but I might need to pass the "pathlen" around as a parameter if we need to handle strings that contain embedded NUL characters. That's an easy thing to do if required, though.

Now, it's possible that nobody wants to do that kind of crazy windows stuff, because even windows people are perfectly fine using regular utf-8. I really dunno. My point is more that this is meant to be very flexible basic infrastructure and that we _could_ do things like that.

		Linus