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

[Linus Torvalds <torvalds@linux-foundation.org>]

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