Cloning repository on Windows with a file name with a trailing . (dot) fails

[TheJoelGray]

Reproduction steps

Attempt to clone a repository on Windows that has a file with a trailing . (dot) in the file name. You can use the example repository with this condition at https://gitlab.com/ThePaleOne/libgit2sharp-test.git. The following code will do this.

var repoUrl = "https://gitlab.com/ThePaleOne/libgit2sharp-test.git";
var _baseDirectory = @"D:\src\test\repo";

Console.WriteLine($"Cloning {repoUrl} to {_baseDirectory}");
Repository.Clone(repoUrl, _baseDirectory);

If you run this code on the same repository on Mac or Linux the repository clones just fine.

The contents of the repository shown below:

Expected behavior

Expect the repository to clone properly.

Actual behavior

The clone process fails with this error

cannot checkout to invalid path 'other.test.file.'
   at LibGit2Sharp.Core.Ensure.HandleError(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 154
   at LibGit2Sharp.Core.Ensure.ZeroResult(Int32 result) in /_/LibGit2Sharp/Core/Ensure.cs:line 172
   at LibGit2Sharp.Core.Proxy.git_clone(String url, String workdir, GitCloneOptions& opts) in /_/LibGit2Sharp/Core/Proxy.cs:line 278
   at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, CloneOptions options) in /_/LibGit2Sharp/Repository.cs:line 824

Version of LibGit2Sharp (release number or SHA1)

Version 0.30.0

Operating system(s) tested; .NET runtime tested

Windows 11 Version 24H2 (failed)
Debian 11 bullseye (works)
Mac Sequoia 15.1 (works)

[ethomson]

I moved this over to https://github.com/libgit2/libgit2, since this is an underlying libgit2 limitation. We enforce this limitation based on a number of things, including the MSDN documentation that instructs:

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".

Since git was built for Linux with zero cares given to cross-platform interoperability, my first two question here are always:

1. Okay, what does git itself do here? and
2. Is what git does sensible?

[bording]

Okay, what does git itself do here?

git clone https://gitlab.com/ThePaleOne/libgit2sharp-test.git
Cloning into 'libgit2sharp-test'...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 11 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (11/11), done.
Resolving deltas: 100% (2/2), done.
error: invalid path 'other.test.file.'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

[ethomson]

Thanks @bording - I didn't have a windows machine to test this with. This seems like libgit2 is consistent with git. Whether this is sensible, I'm not sure about; what would you expect here? 🤔

[TheJoelGray]

Thanks @bording - I didn't have a windows machine to test this with. This seems like libgit2 is consistent with git. Whether this is sensible, I'm not sure about; what would you expect here? 🤔

I suppose I'd expect it to work the same way git works.

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".

I hadn't realized that Windows had that specification. Fortunately, my deployment target is a Linux container so in everyday use it works as expected. I'll just have to keep that in mind if/when I need to do more work with the repository that had that odd file.

Thanks for the follow up!

[bording]

Yeah, I would not expect libgit2 to be more permissive than git itself here.

[anonymepada]

969y