[PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components

[PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components

[Michael Haggerty]

When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where
"foo" does not exist yet, Git would throw an error like

    fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory

Fix this by not hard-coding a platform specific directory separator
into safe_create_leading_directories().

This patch, including its entire commit message, is derived from a
patch by Sebastian Schuberth.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
This patch applies on top of v3 of mh/safe-create-leading-directories.

The only logical change from Sebastian's patch is that this version
restores the original slash character rather than always restoring it
to '/' (as suggested by Junio).

Please note that I have merely adapted Sebastian's patch to apply on
top of my changes.  I do not have an opinion about whether slashes
should rather be normalized before they are passed to this function.
And I cannot test the patch under Windows (though it passes the test
suite under Linux).

 sha1_file.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/sha1_file.c b/sha1_file.c
index 8b0849f..6e8c05d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -112,17 +112,21 @@ enum scld_error safe_create_leading_directories(char *path)
 
 	while (ret == SCLD_OK && next_component) {
 		struct stat st;
-		char *slash = strchr(next_component, '/');
+		char *slash = next_component, slash_character;
 
-		if (!slash)
+		while (*slash && !is_dir_sep(*slash))
+			slash++;
+
+		if (!*slash)
 			break;
 
 		next_component = slash + 1;
-		while (*next_component == '/')
+		while (is_dir_sep(*next_component))
 			next_component++;
 		if (!*next_component)
 			break;
 
+		slash_character = *slash;
 		*slash = '\0';
 		if (!stat(path, &st)) {
 			/* path exists */
@@ -148,7 +152,7 @@ enum scld_error safe_create_leading_directories(char *path)
 		} else if (adjust_shared_perm(path)) {
 			ret = SCLD_PERMS;
 		}
-		*slash = '/';
+		*slash = slash_character;
 	}
 	return ret;
 }
-- 
1.8.5.2

Re: [PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components

[Sebastian Schuberth]

On Sun, Jan 19, 2014 at 12:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

> This patch applies on top of v3 of mh/safe-create-leading-directories.
>
> The only logical change from Sebastian's patch is that this version
> restores the original slash character rather than always restoring it
> to '/' (as suggested by Junio).

Thanks Michael. This is very similar to Junio's current merge conflict
resultion in pu between your original series and my patch (c2fec83). I
like this patch of yours slightly better, however, as it uses a
"while" instead of a "for" loop and the more conclusive
"slash_character" than the "was_slash" variable name.

-- 
Sebastian Schuberth

Re: [PATCH v2] safe_create_leading_directories(): on Windows, \ can separate path components

[Junio C Hamano]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> On Sun, Jan 19, 2014 at 12:40 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>
>> This patch applies on top of v3 of mh/safe-create-leading-directories.
>>
>> The only logical change from Sebastian's patch is that this version
>> restores the original slash character rather than always restoring it
>> to '/' (as suggested by Junio).
>
> Thanks Michael. This is very similar to Junio's current merge conflict
> resultion in pu between your original series and my patch (c2fec83). I
> like this patch of yours slightly better, however, as it uses a
> "while" instead of a "for" loop and the more conclusive
> "slash_character" than the "was_slash" variable name.

Yeah, I agree this patch that uses more descriptive names is a much
more desirable end-result than the tentative merge in 'pu'.