On Mon, Oct 26, 2009 at 01:54:23PM +0000, Matthew Booth wrote:
The alternative here, is to do 2 things:
1. Change the implementation of every existing API call which takes a
Guest path to call the new path resolution function first.
2. Fix up the path resolution function so this is safe to do.
The first shouldn't be too hard because it's all auto-generated. The
second should[n't] be hard to do either, because it's a relatively small
change to your existing patch to make it check the filesystem type
first, before deciding whether to be case-sensitive or case-insensitive.
The result is that reading a file out of a windows config file and then
accessing it will Just Work, as will accessing a file with a
well-defined path on Windows. The library user doesn't need to do
anything extra, and there is no addition to the API.
OK I now understand what you mean. I think that such a large change
to the API is very risky, and I think a lot harder than you imagine
(not all the path parsing code is autogenerated, unfortunately[1], and
also it's not clear what filesystems are case-{in,}sensitive).
And in order to support something which is only used in one very
narrow case: getting a string from a Windows configuration file.
That's why it's better to confine this change to a single API function
that people who do that can use, and everyone else can ignore.
Rich.
[1] Look at recursive_mkdir for example, or mkdtemp, or the functions
that can take either a path or a device.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw