trailing space in directory name breaks git

[hugodro]

A trailing space in a directory name gets msysgit to abort cloning with 'unknown file' error. Eg: /name works/name doesnt work /a file name.txt The "name works" directory is well handled by msysgit, but the "name doesnt work " directory is not created and git aborts. This was found using sparkleshare "v1.2 Oct 6 2013" embedded git (sorry don't have for the time being the mswin machine available to extract the version #). Both Mac and Linux version of git handle the trailing space correctly.

[kusma]

While "unknown file" is vague, I'm not entirely sure what you expect to happen. AFAIK, Windows simply doesn't support directories with trailing spaces.

[hugodro]

Hi,

Auto-removal of the trailing space during checkout/cloning would work for me (with warning msg), assuming the commit/push would treat the revised directory names as a rename rather than delete/create pair. I'd guess the majority of situations where people hit this problem are due to unnoticed typos; it was the case for us.

Regards, Hugo

On 17 Feb, 2014, at 11:06 PM, Erik Faye-Lund wrote:

While "unknown file" is vague, I'm not entirely sure what you expect to happen. AFAIK, Windows simply doesn't support directories with trailing spaces.

— Reply to this email directly or view it on GitHub.

[kusma]

Git doesn't rename things it can't check out. Trailing spaces is not special in that sense, the same goes for unsupported characters, invalid encodings, or too deep paths.

[dscho]

@hugodro please take a minute to consider the suggestion to auto-clobber file names. A hint: consider two directories side by side, hugo and hugo (the latter with a space).

Of course, you could now start writing a patch to Git, allowing for file name transformations from/to the working directory.

Or the typo in the source code repository could be fixed.

[t-b]

http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx states

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

So there is little git can and should do here.

[dscho]

I guess this settles the issue.

[hugodro]

Hi,

Comments inlined: On 19 Feb, 2014, at 10:08 pm, t-b notifications@github.com wrote:

http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx states

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not. However, it is acceptable to specify a period as the first character of a name. For example, ".temp".

Indeed that's the cause of the problem we have when using git under ms-windows. So there is little git can and should do here.

msysgit should do a similar job as it does handling other incompatibilities of ms-win vs the unix kind of filesystem. Git in mac/unix world is handling a space-ended directory name graciously; in the ms-win world it aborts the work and throws misleading error messages. At minimum msysgit should not halt, and provide indicative error message.

[hugodro]

The issue is not settled, msysgit behaviour vs the git in unix/mac world is buggy when it reacts to the space-ending directory name by halting and not providing the proper error message to pinpoint the reason for halting.

On 19 Feb, 2014, at 10:21 pm, dscho notifications@github.com wrote:

I guess this settles the issue.

— Reply to this email directly or view it on GitHub.

[hugodro]

Comments inlined: On 18 Feb, 2014, at 8:40 pm, dscho notifications@github.com wrote:

@hugodro please take a minute to consider the suggestion to auto-clobber file names. A hint: consider two directories side by side, hugo and hugo (the latter with a space).

@dscho: thanks for your hint; I actually did spend quite a few minutes on the problem we got due to having directory names with trailing spaces (and not). The finding is: on a ~120 machine network spread out in 3 countries, on a monthly basis, the auto-clobber filename behaviour implemented in msysgit would save about 150 hours of IT support desk work and approx a 5000 files long history review a week. So it's a really good fix. I won't bother you with the details of how we got there, I'm sure you can derive the whole thought process yourself with a good simulation of such an environment in which the msysgit issue popped out. Of course, you could now start writing a patch to Git, allowing for file name transformations from/to the working directory.

It goes without saying. I suppose I should not even bother mentioning the situation in the issue forum, that would be kind of redundant, wouldn't it.

Or the typo in the source code repository could be fixed.

Yes, that would be really great. Out of curiosity, why isn't the whole issue with long path names that populates the msysgit forum addressed with the same approach? That seems to generate lots of twisted behaviour going into the git code... By getting people to stick to 8 characters file/dir name length and limiting their directory tree depth to 2 levels, you take care of the whole thing and you still have an insane 3 x 10^24 file / dir name combinations with A-Z chars to work with. Add a 3 letter extension for more name space size, and bingo, problem solved!

Lucky for me, I don't take care of software problems anymore, I count on our IT dept to take care of that for me. Makes my life much simpler 8-)

[dscho]

@hugodro so you work for a company that relies on a fix? And despite saving you tons of money, you expect the msysGit team to take care of it for free?

Just clarifying.

[hugodro]

No (msysgit fix is one of the possible solution, we'll pick the best valued one) and yes. I assumed that your front-page statement "As an open source project, Git for Windows benefits greatly from both the volunteer work of helpful developers and the bug reports made by Git for Windows' users" meant you were not operating on a commercial basis. Please explain your corporate structure and business model, I can't see any information about that on your wiki/github pages and that front-page statement is misleading on how you ("the team") operate.

[dscho]

@hugodro there is no corporate structure or business model behind the Git for Windows effort.

[t-b]

(Shameless self promotion) For my cross platform projects I use a pre commit hook, found here, to enforce legal windows filenames. Maybe this helps in your situation too?

[dscho]

@t-b I think that is no shameless self-promotion but maybe something so helpful that we might want to put it prominently on our Wiki?