Long filenames in cyrillic(russian) don't recognize.

[blackmore466]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

Git version: 2.28.0.windows.1
Windows 10 Pro

$ git config --global core.longpaths
true

Details

I have git repo with 4 files. One of them has long cyrillic name.

Git Bash doesn't process it.

[dscho]

My gut feeling tells me that the root cause is msys2/MSYS2-packages#1974. Could you run cmd //c chcp 65001 and try again?

[blackmore466]

It repaired unreadable symbols. But problem with long names is still here

[dscho]

But problem with long names is still here

You mean the ls-la problem?

[blackmore466]

Yes. And git add * or git rm

[dscho]

Could you re-test with the latest snapshot, please?

[blackmore466]

This snapshot didn't solve the problem.
But I found workaround solution: if I use git add/git rm with double-quotes it works

Problem with ls still remained. But it's not so important now.
Issue can be closed. Thanks!

[dscho]

But I found workaround solution: if I use git add/git rm with double-quotes it works

Oh, that's a good find! In the unquoted version, it is Bash's job to expand the wildcard, in the quoted version, it is Git's job (I think). So the remaining problem lies with Bash, apparently...

[dscho]

@blackmore466 did you have a chance to look into this more deeply?

[blackmore466]

So the remaining problem lies with Bash, apparently...

Yes, it's Linux limitation for filename length
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Git is just victim :)

[rimrul]

The specific limitation seems to be the length of d_name in struct dirent. This should stay limited to NAME_MAX + 1, so a fix could be to increase NAME_MAX.

Assuming that Wikipedia page is correct and I'm reading it correctly the NTFS limit is 255 UTF-16 code points (2 bytes each), so increasing NAME_MAX to 510 should do the trick. I have no clue what downsides and side-effects that could have, though.