| Message ID | 13c06a8129b13a672d3b8329db83db103607787b.1728992306.git.ps@pks.im (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Platform compatibility fixes | expand |
On Tue Oct 15, 2024 at 10:45 PM AEDT, Patrick Steinhardt wrote: > Windows by default has a restriction in place to only allow paths up to > 260 characters. This restriction can nowadays be lifted by setting a > registry key, but is still active by default. > > In t7300 we have one test that exercises the behaviour of git-clean(1) > with such long paths. Interestingly enough, this test fails on my system > that uses Windows 10 with mingw-w64 installed via MSYS2: instead of > observing ENAMETOOLONG, we observe ENOENT. This behaviour is consistent > across multiple different environments I have tried. > > I cannot say why exactly we observe a different error here, but I would > not be surprised if this was either dependent on the Windows version, > the version of MinGW, the current working directory of Git or any kind > of combination of these. That's very strange. I'll try it on my Windows 11 23H2 system to see if I can observe the same behaviour. I think it's fine to just catch both cases in the test anyway.
On Wed Oct 16, 2024 at 5:35 PM AEDT, James Liu wrote: > On Tue Oct 15, 2024 at 10:45 PM AEDT, Patrick Steinhardt wrote: > > Windows by default has a restriction in place to only allow paths up to > > 260 characters. This restriction can nowadays be lifted by setting a > > registry key, but is still active by default. > > > > In t7300 we have one test that exercises the behaviour of git-clean(1) > > with such long paths. Interestingly enough, this test fails on my system > > that uses Windows 10 with mingw-w64 installed via MSYS2: instead of > > observing ENAMETOOLONG, we observe ENOENT. This behaviour is consistent > > across multiple different environments I have tried. > > > > I cannot say why exactly we observe a different error here, but I would > > not be surprised if this was either dependent on the Windows version, > > the version of MinGW, the current working directory of Git or any kind > > of combination of these. > > That's very strange. I'll try it on my Windows 11 23H2 system to see if > I can observe the same behaviour. Hmm maybe not. MSYS2 on ARM64 isn't fully baked, and I don't have an x86 Windows machine handy.
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh index 0aae0dee670..12ab25296b0 100755 --- a/t/t7300-clean.sh +++ b/t/t7300-clean.sh @@ -747,7 +747,7 @@ test_expect_success MINGW 'handle clean & core.longpaths = false nicely' ' test_must_fail git clean -xdf 2>.git/err && # grepping for a strerror string is unportable but it is OK here with # MINGW prereq - test_grep "too long" .git/err + test_grep -e "too long" -e "No such file or directory" .git/err ' test_expect_success 'clean untracked paths by pathspec' '
Windows by default has a restriction in place to only allow paths up to 260 characters. This restriction can nowadays be lifted by setting a registry key, but is still active by default. In t7300 we have one test that exercises the behaviour of git-clean(1) with such long paths. Interestingly enough, this test fails on my system that uses Windows 10 with mingw-w64 installed via MSYS2: instead of observing ENAMETOOLONG, we observe ENOENT. This behaviour is consistent across multiple different environments I have tried. I cannot say why exactly we observe a different error here, but I would not be surprised if this was either dependent on the Windows version, the version of MinGW, the current working directory of Git or any kind of combination of these. Work around the issue by handling both errors. Signed-off-by: Patrick Steinhardt <ps@pks.im> --- t/t7300-clean.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)