[Libguestfs] [PATCH 2/5] daemon error handling: fix case_sensitive_path for Windows.

Matthew Booth mbooth at redhat.com
Mon Nov 30 15:45:20 UTC 2009


On 30/11/09 14:42, Richard W.M. Jones wrote:
>> From 23452a49f51458ca39ca4c2c953169f32ed67067 Mon Sep 17 00:00:00 2001
> From: Richard Jones<rjones at redhat.com>
> Date: Fri, 27 Nov 2009 13:54:11 +0000
> Subject: [PATCH 2/5] daemon error handling: fix case_sensitive_path for Windows.
>
> ---
>   daemon/realpath.c |   12 ++++++++++++
>   1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/daemon/realpath.c b/daemon/realpath.c
> index e6c81ef..0edb1d0 100644
> --- a/daemon/realpath.c
> +++ b/daemon/realpath.c
> @@ -69,6 +69,7 @@ do_realpath (const char *path)
>   char *
>   do_case_sensitive_path (const char *path)
>   {
> +#ifndef WIN32
>     char ret[PATH_MAX+1] = "/";
>     size_t next = 1;
>     int fd_cwd;
> @@ -196,4 +197,15 @@ do_case_sensitive_path (const char *path)
>    error:
>     close (fd_cwd);
>     return NULL;
> +#else /* WIN32 */
> +  /* On Win32 paths are always handled case insensitively, so there is
> +   * no need for this function to modify the path in any way.
> +   */
> +  char *ret = strdup (path);
> +  if (ret == NULL) {
> +    reply_with_perror ("strdup");
> +    return NULL;
> +  }
> +  return ret;
> +#endif /* WIN32 */
>   }
> -- 1.6.5.2

I'm not convinced by this. I know this call isn't required on Windows. 
However, making it a no-op on a Windows appliance is one of those minor, 
unexpected behaviour differences which is going to bite you in the arse 
later. For example, storing the output of case_sensitive_path for later 
use by a Linux appliance. It is feasible to keep the behaviour on Windows?

Matt
-- 
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

M:       +44 (0)7977 267231
GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490




More information about the Libguestfs mailing list