[Evolution-hackers] Re: Symptom-fixing for Win32 paths

[Tor Lillqvist <tml novell com>]

to 2006-01-19 klockan 23:12 +0100 skrev Philip Van Hoof:

> in mail_component_init somebody (I'm assuming you) did something like
> this:
> 
> #ifdef G_OS_WIN32
> 	{
> 		char *p = priv->base_directory;
> 		while ((p = strchr(p, '\\')))
> 			*p++ = '/';
> 	}
> #endif
> 
> IMHO this is high level symptom-fixing. Wouldn't it be better to fix
> camel in such a way that it accepts Win32 paths with "\" characters?

In general, yes, and such fixes indeed have been added wherever
necessary, I hope. The code has been changed to use GLib path and URI
manipulation functions and macros instead of "manually" scanning for '/'
or constructing file: URIs by just prefixing "file://".

But the case you mention is a special one, as base_directory is used to
set up an mbox: URI (see mc_setup_local_store()), and we don't want
backslashes in URIs. OK, so maybe it would have been cleaner to do the
backslash-to-slash change on a temporary string as late as possible, in
mc_setup_local_store(). But it might be, I don't recall if I tested
this, that this wouldn't work, if some code later compares parts of URIs
to the base_directory. Then such comparisons would have to be changed to
treat both slashes as equal, etc.

I will add a comment at that code snippet explaining the rationale for
it...

> Maybe tomorrow we'll have an Operating System that doesn't use character
> delimited paths in a string (or whatever or however).

Considering how many details that had to be fixed here and there in
Evolution and dependencies just for Win32, where pathnames after all are
*almost* like Unix, such an operating system would then surely need
massive changes. 

Anyway, I don't really think there is much chance that such an operating
system will appear; no matter how non-Unixish some future operating
system might be in the core, I find it very likely that it will offer a
POSIX layer with POSIX file names on top (or, heaven forbid, a Win32
layer...) Didn't even VMS transmogrify into OpenVMS, providing POSIX
pathnames, too, or am I mistaken?

> Wouldn't fixing the implementations for camel_session_construct and
> camel_mkdir be a better solution?

camel_mkdir() has been replaced with g_mkdir_with_parents() in HEAD, and
that function, like all GLib functions, and the underlying Microsoft C
library and Win32 API functions, accept both kinds of slashes.

--tml