{"thread":{"id":"65974","subject":"cygwin v2.55.0 test failures","startedAt":"2026-07-10T18:35:35Z","lastAt":"2026-07-13T20:28:54Z","messageCount":5,"participants":["Ramsay Jones","Torsten Bögershausen","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"547791","messageId":"f65466c9-bede-472e-ad57-e72a5289be27@ramsayjones.plus.com","threadId":"65974","inReplyTo":null,"subject":"cygwin v2.55.0 test failures","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2026-07-10T18:32:23Z","receivedAt":"2026-07-10T18:35:35Z","isPatch":false,"body":"\nSorry for being a bit tardy, but I was somewhat unwell and, as a result,\nAFK for some weeks during the last part of the v2.55.0 cycle. So, I'm\nstill catching up. As part of that, I found that the cygwin test-suite\nfails for v2.55.0, like so:\n\n  $ tail -13 test-out-2-55-rel\n  Test Summary Report\n  -------------------\n  unit-tests/bin/unit-tests.exe                    (Wstat: 256 (exited 1) Tests: 249 Failed: 1)\n    Failed test:  242\n    Non-zero exit status: 1\n  t9904-url-parse.sh                               (Wstat: 256 (exited 1) Tests: 53 Failed: 4)\n    Failed tests:  39, 42-43, 47\n    Non-zero exit status: 1\n  Files=1047, Tests=32848, 4584 wallclock secs (29.05 usr 85.59 sys + 9679.08 cusr 14883.94 csys = 24677.67 CPU)\n  Result: FAIL\n  make[1]: *** [Makefile:78: prove] Error 1\n  make[1]: Leaving directory '/home/ramsay/git/t'\n  make: *** [Makefile:3381: test] Error 2\n  $ \n\nUnsurprisingly, the -rc0, -rc1 and -rc2 builds show the same failures.\n\nAfter a quick squint, the reason for the failure looked familiar ... ;)\nIndeed, I have been aware of the reason for this failure since v2.23.1\nat the end of 2019. For those who don't instantly recognize it, this was\none of a series of security releases, which mainly affected GfW. From\nthe release Notes:\n\n  Git v2.23.1 Release Notes\n  =========================\n  \n  This release merges up the fixes that appear in v2.14.6, v2.15.4,\n  v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues\n  CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351,\n  CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and\n  CVE-2019-19604; see the release notes for those versions for details.\n\nFor example, the test-suite for v2.25.0-rc0 looks like:\n\n  $ tail -17 test-out/test-out-2-25-rc0\n  Test Summary Report\n  -------------------\n  t5500-fetch-pack.sh                              (Wstat: 256 Tests: 369 Failed: 12)\n    Failed tests:  142, 145, 161-162, 239, 242, 258-259, 336\n                  339, 355-356\n    Non-zero exit status: 1\n  t5580-clone-push-unc.sh                          (Wstat: 256 Tests: 6 Failed: 1)\n    Failed test:  4\n    Non-zero exit status: 1\n  t5601-clone.sh                                   (Wstat: 256 Tests: 104 Failed: 4)\n    Failed tests:  62-64, 66\n    Non-zero exit status: 1\n  Files=890, Tests=21098, 16304 wallclock secs ( 0.48 usr  0.73 sys + 2374.33 cusr 7438.69 csys = 9814.24 CPU)\n  Result: FAIL\n  make[1]: *** [Makefile:52: prove] Error 1\n  make[1]: Leaving directory '/home/ramsay/git/t'\n  make: *** [Makefile:2754: test] Error 2\n  $ \n\n[t5580-clone-push-unc.sh was later renamed to t5580-unc-paths.sh]\n\nFrom about that time, I had hacked up a 'fix' for cygwin, but hadn't decided\nhow to proceed with an actual patch. :)\n\nSo, I cherry-picked the 'fix' onto 'master' (then on v2.55.0 release). I was\na little surprised it went without problem, given how much 'git-compat-util.h'\nhas changed, but it just required a 'slide' from line 203 back to line 153.\nThis patch is equivalent to the 'git-compat-util.h' only part of the patch\ngiven below.\n\nThis fixed up the current test failures (unit-tests and t9904-url-parse.sh).\n\nNote that Patrick wanted to have a clean test-suite run on cygwin, so in\ncommit 5f8af25ff9 (\"t5500, t5601: skip tests which exercise paths with '[::1]'\non Cygwin\", 2024-10-16), he suppressed the test failures in t5500 and t5601.\n(that was about the time of the v2.48.0 release).\n\nThe changes to tests t5500 and t5601, in the patch given below, essentially\nreverts Patrick's commit 5f8af25ff9. This fixes all of the tests in t5601 and\nten of the twelve failures in t5500. (I don't recall what happened to t5580,\nthe single failure - the push test - was fixed somewhere between v2.43.0 and\nv2.44.0-rc0).\n\nAs luck would have it, I left a note to myself about the remaining two\nfailure cases. This leads to the remaining hunk, to connect.c, in the patch\nbelow; ie. the removal of a conditional (which should only fire for GfW and\ncygwin). The '#ifdef DUMMY/#endif' should probably be replaced with an\n'#ifdef GIT_WINDOWS_NATIVE/#endif' so that GfW is not affected. (Having said\nthat, I suspect that even GfW should drop it ['somebody was smoking something\nexotic'], but I have no way to test it, so ...).\n\nWith this final hunk, this patch results in a clean test-suite run. :)\n\nSo, what does this mean? Well, I should probably not leave it another five\nyears, or thereabouts, before actually sending a real patch (series) to fix\nthis up properly! ;)\n\nBut what is properly? The 'fix' works, but the problem was principally caused\nby cygwin being a bit schizophrenic about the 'pathname utilities' and its\nsupport for POSIX only paths, WIN32 only paths or both.\n\nFor example, f82a97eb91 (\"mingw: handle `subst`-ed \"DOS drives\"\", 2019-09-06)\nnotes in the commit message:\n\n    Note: `[::1]:repo` is a valid URL, but not a valid path on Windows.\n    As `[` is now considered a valid drive letter, we need to be very\n    careful to avoid misinterpreting such a string as valid local path in\n    `url_is_local_not_ssh()`. To do that, we use the just-introduced\n    function `is_valid_path()` (which will label the string as invalid file\n    name because of the colon characters).\n    \n    This fixes CVE-2019-1351.\n\nNote that part of the fix involves a cygwin specific 'is_valid_path()' which\nwould otherwise be defined, like Linux, as simply '1' in git-compat-util.h.\nI was a bit surprised that an IPv6 address was not parsed at a higher level\nand take priority over an (possible) '[' drive letter, rather than being a\nside-effect of calling an 'is_valid_path()' helper function. ;)\n\nThe 'is_valid_path()' was also part of the security fixes to check for some\n'illegal' win32 paths which included those ending in spaces or periods or\nfor names such as AUX, COM1, LPTn, NUL, PRN, CONIN$, etc,. I know that some\nof these paths are valid in cygwin (eg. those ending in spaces or periods)\nso the win32 version of that function cannot be used without change. (this\ncould lead to one part of git allowing you to use said paths and other\nparts not)! Note that some of the CVEs may actually still apply to cygwin.\nI didn't check.\n\nAlso, note that I replaced the win32 version of the 'offset_1st_component()'\nfunction. I can't quite remember why I did that, but I think the fact that\nthe win32 version doesn't ensure that the 'path' consists of both the <server>\nand <share> component before returning the offset. (ie make sure that the\n'path' consists of \"//<server>/<share>/\" at the very least and return one,\nfor '/', otherwise).\n\nPersonally, I would be quite happy to rip out all win32 path handling and\nonly support POSIX paths (I have been using cygwin since about 1996 and\nhave only ever used win32 paths when testing git ... that is the whole\npoint of cygwin! :) ), but I already know that that is a no-go. (there is\nalways somebody that complains when you suggest it).\n\nSo, for now anyway, it seems that I need to tidy up the patch and move in\nthe opposite direction to e.g. commit 1cadad6f65 (\"git clone <url> \nC:\\cygwin\\home\\USER\\repo' is working (again)\", 2018-12-15).\n\nPart of the reason for vacillating on the correct way forward with this\npatch, was because I have often thought that I should use the cygwin API\nto cater to both POSIX and win32 paths. For example, we could possibly use\nthe 'cygwin_conv_path()' function to do the path conversion (somewhat\nsimilar to the macos pre-composed-utf8 stuff, minus the directory reading).\nHowever, I think that would open a different can of worms, including some\npotential memory leaks. So, not exactly a slam dunk.\n\n[I also had a note-to-self about 'mixed / and \\ urls' in the config file\nwhich is exposed by these same tests. So, another patch may be needed?]\n\nAnyway, something to think about. Hmm, I suspect it would be best to just\ntidy up this patch first. ;)\n\nJust FYI. Thanks!\n\nATB,\nRamsay Jones\n\n\n----- >8 -----\nSubject: [PATCH] cygwin: fix up IPv6 scp urls\n\n---\n connect.c             |  2 ++\n git-compat-util.h     | 39 +++++++++++++++++++++++++++++++++++++++\n t/t5500-fetch-pack.sh | 14 ++++----------\n t/t5601-clone.sh      | 11 ++---------\n 4 files changed, 47 insertions(+), 19 deletions(-)\n\ndiff --git a/connect.c b/connect.c\nindex 47e39d2a73..6f5715e938 100644\n--- a/connect.c\n+++ b/connect.c\n@@ -1088,10 +1088,12 @@ static enum url_scheme parse_connect_url(const char *url_orig, char **ret_host,\n \n \tif (scheme == URL_SCHEME_LOCAL)\n \t\tpath = end;\n+#ifdef DUMMY\n \telse if (scheme == URL_SCHEME_FILE && *host != '/' &&\n \t\t !has_dos_drive_prefix(host) &&\n \t\t offset_1st_component(host - 2) > 1)\n \t\tpath = host - 2; /* include the leading \"//\" */\n+#endif\n \telse if (scheme == URL_SCHEME_FILE && has_dos_drive_prefix(end))\n \t\tpath = end; /* \"file://$(pwd)\" may be \"file://C:/projects/repo\" */\n \telse\ndiff --git a/git-compat-util.h b/git-compat-util.h\nindex 8809776407..645ff96048 100644\n--- a/git-compat-util.h\n+++ b/git-compat-util.h\n@@ -153,6 +153,45 @@ static inline int is_xplatform_dir_sep(int c)\n \n #if defined(__CYGWIN__)\n #include \"compat/win32/path-utils.h\"\n+\n+static inline int is_valid_cygwin_path(const char *path)\n+{\n+\tif (path && strlen(path) > 2 &&\n+\t    path[0] == '[' && path[1] == ':' &&\n+\t    strchr(&path[2], ':'))\n+\t\treturn 0;\n+\treturn 1;\n+}\n+\n+#define is_valid_path(path) is_valid_cygwin_path(path)\n+\n+static inline int cygwin_offset_1st_component(const char *path)\n+{\n+\tint ret = 0;\n+\n+\t/* C: prefix */\n+\tif ((ret = has_dos_drive_prefix(path)))\n+\t\treturn ret;\n+\n+\t/* //server/share/ prefix */\n+\tif (is_dir_sep(path[0]) && is_dir_sep(path[1])) {\n+\t\tchar *pos = strpbrk(path + 2, \"\\\\/\");\n+\t\tif (pos && *(pos + 1) && !is_dir_sep(*(pos + 1))) {\n+\t\t\tpos = strpbrk(pos + 1, \"\\\\/\");\n+\t\t\tif (pos && *(pos + 1))\n+\t\t\t\treturn pos + 1 - path;\n+\t\t}\n+\t}\n+\n+\t/* / prefix */\n+\tif (is_dir_sep(path[0]))\n+\t\treturn 1;\n+\n+\treturn 0;\n+}\n+\n+#undef offset_1st_component\n+#define offset_1st_component cygwin_offset_1st_component\n #endif\n #if defined(__MINGW32__)\n /* pull in Windows compatibility stuff */\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex 649a615ec9..2c6c0a04be 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -774,7 +774,7 @@ do\n \t# file with scheme\n \tfor p in file\n \tdo\n-\t\ttest_expect_success !WINDOWS \"fetch-pack --diag-url $p://$h/$r\" '\n+\t\ttest_expect_success !MINGW \"fetch-pack --diag-url $p://$h/$r\" '\n \t\t\tcheck_prot_path $p://$h/$r $p \"/$r\"\n \t\t'\n \t\ttest_expect_success MINGW \"fetch-pack --diag-url $p://$h/$r\" '\n@@ -784,7 +784,7 @@ do\n \t\t\tcheck_prot_path $p:///$r $p \"/$r\"\n \t\t'\n \t\t# No \"/~\" -> \"~\" conversion for file\n-\t\ttest_expect_success !WINDOWS \"fetch-pack --diag-url $p://$h/~$r\" '\n+\t\ttest_expect_success !MINGW \"fetch-pack --diag-url $p://$h/~$r\" '\n \t\t\tcheck_prot_path $p://$h/~$r $p \"/~$r\"\n \t\t'\n \t\ttest_expect_success MINGW \"fetch-pack --diag-url $p://$h/~$r\" '\n@@ -806,17 +806,11 @@ do\n \tp=ssh\n \tfor h in host [::1]\n \tdo\n-\t\texpectation=\"success\"\n-\t\tif test_have_prereq CYGWIN && test \"$h\" = \"[::1]\"\n-\t\tthen\n-\t\t\texpectation=\"failure\"\n-\t\tfi\n-\n-\t\ttest_expect_$expectation \"fetch-pack --diag-url $h:$r\" '\n+\t\ttest_expect_success \"fetch-pack --diag-url $h:$r\" '\n \t\t\tcheck_prot_host_port_path $h:$r $p \"$h\" NONE \"$r\"\n \t\t'\n \t\t# Do \"/~\" -> \"~\" conversion\n-\t\ttest_expect_$expectation \"fetch-pack --diag-url $h:/~$r\" '\n+\t\ttest_expect_success \"fetch-pack --diag-url $h:/~$r\" '\n \t\t\tcheck_prot_host_port_path $h:/~$r $p \"$h\" NONE \"~$r\"\n \t\t'\n \tdone\ndiff --git a/t/t5601-clone.sh b/t/t5601-clone.sh\nindex 3dd229c186..35e9f3eb0d 100755\n--- a/t/t5601-clone.sh\n+++ b/t/t5601-clone.sh\n@@ -530,17 +530,10 @@ do\n \t'\n done\n \n-# Parsing of paths that look like IPv6 addresses is broken on Cygwin.\n-expectation_for_ipv6_tests=success\n-if test_have_prereq CYGWIN\n-then\n-\texpectation_for_ipv6_tests=failure\n-fi\n-\n #ipv6\n for repo in rep rep/home/project 123\n do\n-\ttest_expect_$expectation_for_ipv6_tests \"clone [::1]:$repo\" '\n+\ttest_expect_success \"clone [::1]:$repo\" '\n \t\ttest_clone_url [::1]:$repo ::1 \"$repo\"\n \t'\n done\n@@ -553,7 +546,7 @@ test_expect_success !SANITIZE_LEAK \"clone host:/~repo\" '\n \ttest_clone_url host:/~repo host \"~repo\"\n '\n \n-test_expect_$expectation_for_ipv6_tests !SANITIZE_LEAK \"clone [::1]:/~repo\" '\n+test_expect_success !SANITIZE_LEAK \"clone [::1]:/~repo\" '\n \ttest_clone_url [::1]:/~repo ::1 \"~repo\"\n '\n \n-- \n2.55.0\n"},{"id":"547919","messageId":"20260712200426.GA11328@tb-raspi4","threadId":"65974","inReplyTo":"f65466c9-bede-472e-ad57-e72a5289be27@ramsayjones.plus.com","subject":"Re: cygwin v2.55.0 test failures","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2026-07-12T20:04:27Z","receivedAt":"2026-07-12T20:04:39Z","isPatch":false,"body":"On Fri, Jul 10, 2026 at 07:32:23PM +0100, Ramsay Jones wrote:\n\n[snip]\nHej Ramsay,\n Thanks for picking this up - I have some smaller comments inline,\n trying to be helpful.\n\n> As luck would have it, I left a note to myself about the remaining two\n> failure cases. This leads to the remaining hunk, to connect.c, in the patch\n> below; ie. the removal of a conditional (which should only fire for GfW and\n> cygwin). The '#ifdef DUMMY/#endif' should probably be replaced with an\n> '#ifdef GIT_WINDOWS_NATIVE/#endif' so that GfW is not affected. (Having said\n> that, I suspect that even GfW should drop it ['somebody was smoking something\n> exotic'], but I have no way to test it, so ...).\n\n> Personally, I would be quite happy to rip out all win32 path handling and\n> only support POSIX paths (I have been using cygwin since about 1996 and\n> have only ever used win32 paths when testing git ... that is the whole\n> point of cygwin! :) ), but I already know that that is a no-go. (there is\n> always somebody that complains when you suggest it).\n\nAs cygwin supports/allows win32 paths: we do support them in Git as well.\n(and nobody is forced to use them)\n\n> \n> So, for now anyway, it seems that I need to tidy up the patch and move in\n> the opposite direction to e.g. commit 1cadad6f65 (\"git clone <url> \n> C:\\cygwin\\home\\USER\\repo' is working (again)\", 2018-12-15).\n> \n> Part of the reason for vacillating on the correct way forward with this\n> patch, was because I have often thought that I should use the cygwin API\n> to cater to both POSIX and win32 paths. For example, we could possibly use\n> the 'cygwin_conv_path()' function to do the path conversion (somewhat\n> similar to the macos pre-composed-utf8 stuff, minus the directory reading).\n> However, I think that would open a different can of worms, including some\n> potential memory leaks. So, not exactly a slam dunk.\n> \n> [I also had a note-to-self about 'mixed / and \\ urls' in the config file\n> which is exposed by these same tests. So, another patch may be needed?]\nNot sure if I follow. cygwin allows mixed / and \\ . What should be patched ? \n> \n> Anyway, something to think about. Hmm, I suspect it would be best to just\n> tidy up this patch first. ;)\n> \n> Just FYI. Thanks!\n> \n> ATB,\n> Ramsay Jones\n> diff --git a/connect.c b/connect.c\n> index 47e39d2a73..6f5715e938 100644\n> --- a/connect.c\n> +++ b/connect.c\n> @@ -1088,10 +1088,12 @@ static enum url_scheme parse_connect_url(const char *url_orig, char **ret_host,\n>  \n>  \tif (scheme == URL_SCHEME_LOCAL)\n>  \t\tpath = end;\n> +#ifdef DUMMY\n>  \telse if (scheme == URL_SCHEME_FILE && *host != '/' &&\n>  \t\t !has_dos_drive_prefix(host) &&\n>  \t\t offset_1st_component(host - 2) > 1)\n>  \t\tpath = host - 2; /* include the leading \"//\" */\n> +#endif\n\nThis very lines come from\n\ncommit ebb8d2c90fb0840a0803935804e37e2205505f23\n  mingw: support UNC in git clone file://server/share/repo\n\n...and I can not see a reason to remove it.\n\n"},{"id":"547973","messageId":"alTGqS2_RmfGHvfV@pks.im","threadId":"65974","inReplyTo":"f65466c9-bede-472e-ad57-e72a5289be27@ramsayjones.plus.com","subject":"Re: cygwin v2.55.0 test failures","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-07-13T11:06:17Z","receivedAt":"2026-07-13T11:06:26Z","isPatch":false,"body":"On Fri, Jul 10, 2026 at 07:32:23PM +0100, Ramsay Jones wrote:\n[snip]\n> Note that Patrick wanted to have a clean test-suite run on cygwin, so in\n> commit 5f8af25ff9 (\"t5500, t5601: skip tests which exercise paths with '[::1]'\n> on Cygwin\", 2024-10-16), he suppressed the test failures in t5500 and t5601.\n> (that was about the time of the v2.48.0 release).\n> \n> The changes to tests t5500 and t5601, in the patch given below, essentially\n> reverts Patrick's commit 5f8af25ff9. This fixes all of the tests in t5601 and\n> ten of the twelve failures in t5500. (I don't recall what happened to t5580,\n> the single failure - the push test - was fixed somewhere between v2.43.0 and\n> v2.44.0-rc0).\n\nYeah, this was merely papering over issues. I'd very much welcome a\nrevert and proper fix for this.\n\n> As luck would have it, I left a note to myself about the remaining two\n> failure cases. This leads to the remaining hunk, to connect.c, in the patch\n> below; ie. the removal of a conditional (which should only fire for GfW and\n> cygwin). The '#ifdef DUMMY/#endif' should probably be replaced with an\n> '#ifdef GIT_WINDOWS_NATIVE/#endif' so that GfW is not affected. (Having said\n> that, I suspect that even GfW should drop it ['somebody was smoking something\n> exotic'], but I have no way to test it, so ...).\n> \n> With this final hunk, this patch results in a clean test-suite run. :)\n\nNice :)\n\nBy the way: I was pondering multiple times over whether or not we should\nadd Cygwin to our CI matrix. It seems to be sufficiently different from\nboth MSYS2 and native Win32 to have its own set of compatibility issues,\nso that could be worth it?\n\n>  connect.c             |  2 ++\n>  git-compat-util.h     | 39 +++++++++++++++++++++++++++++++++++++++\n>  t/t5500-fetch-pack.sh | 14 ++++----------\n>  t/t5601-clone.sh      | 11 ++---------\n>  4 files changed, 47 insertions(+), 19 deletions(-)\n\nFor the record: I don't really have much of an opinion on this given\nthat I tend to not use Windows, except when I (once again) break some\ntests there. Especially the path handling si something that tends to\ncause lots of confusion on my side.\n\nPatrick\n"},{"id":"548036","messageId":"82ef71fc-8099-48dd-b841-87188bd39fa0@ramsayjones.plus.com","threadId":"65974","inReplyTo":"20260712200426.GA11328@tb-raspi4","subject":"Re: cygwin v2.55.0 test failures","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2026-07-13T20:15:28Z","receivedAt":"2026-07-13T20:15:38Z","isPatch":false,"body":"\n\nOn 12/07/2026 9:04 pm, Torsten Bögershausen wrote:\n> On Fri, Jul 10, 2026 at 07:32:23PM +0100, Ramsay Jones wrote:\n[snip]\n>> [I also had a note-to-self about 'mixed / and \\ urls' in the config file\n>> which is exposed by these same tests. So, another patch may be needed?]\n> Not sure if I follow. cygwin allows mixed / and \\ . What should be patched ? \n\nYes, maybe nothing needs patching - it was a note-to-self to check that the\nmixed urls don't cause any issues and, maybe, normalize the urls before\nwriting them to the config.\n\n>>\n>> Anyway, something to think about. Hmm, I suspect it would be best to just\n>> tidy up this patch first. ;)\n>>\n>> Just FYI. Thanks!\n>>\n>> ATB,\n>> Ramsay Jones\n>> diff --git a/connect.c b/connect.c\n>> index 47e39d2a73..6f5715e938 100644\n>> --- a/connect.c\n>> +++ b/connect.c\n>> @@ -1088,10 +1088,12 @@ static enum url_scheme parse_connect_url(const char *url_orig, char **ret_host,\n>>  \n>>  \tif (scheme == URL_SCHEME_LOCAL)\n>>  \t\tpath = end;\n>> +#ifdef DUMMY\n>>  \telse if (scheme == URL_SCHEME_FILE && *host != '/' &&\n>>  \t\t !has_dos_drive_prefix(host) &&\n>>  \t\t offset_1st_component(host - 2) > 1)\n>>  \t\tpath = host - 2; /* include the leading \"//\" */\n>> +#endif\n> \n> This very lines come from\n> \n> commit ebb8d2c90fb0840a0803935804e37e2205505f23\n>   mingw: support UNC in git clone file://server/share/repo\n> \n> ...and I can not see a reason to remove it.\n\nHeh, I just read a few references [1][2][3] about file URIs to refresh my\nmemory (I read the RFCs many many moons ago ... and they seem to have\nchanged in the meantime? At least I don't remember it said that! :) ).\n\nI seem to have misremembered the 'number of slashes' after the 'file:'\nprefix as three or four, not two (specifically with a windows UNC or\nabsolute path). However, I was clearly wrong!\n\n[The 'non-standard' rules on win32 are wild - git clearly doesn't support\nall the edge cases].\n\nOK, so I probably need to look at the two failing tests again - maybe I\nneed to mark them with !CYGWIN.\n\nAnyway, more work to do! ;)\n\nATB,\nRamsay Jones\n\n[1] https://en.wikipedia.org/wiki/File_URI_scheme\n[2] https://datatracker.ietf.org/doc/rfc8089/\n[3] https://learn.microsoft.com/en-us/archive/blogs/ie/file-uris-in-windows\n\n\n\n\n"},{"id":"548038","messageId":"910f130f-ea0b-4086-a43f-3842b0df0fce@ramsayjones.plus.com","threadId":"65974","inReplyTo":"alTGqS2_RmfGHvfV@pks.im","subject":"Re: cygwin v2.55.0 test failures","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2026-07-13T20:28:51Z","receivedAt":"2026-07-13T20:28:54Z","isPatch":false,"body":"\n\nOn 13/07/2026 12:06 pm, Patrick Steinhardt wrote:\n> On Fri, Jul 10, 2026 at 07:32:23PM +0100, Ramsay Jones wrote:\n> [snip]\n[snip]\n> \n> By the way: I was pondering multiple times over whether or not we should\n> add Cygwin to our CI matrix. It seems to be sufficiently different from\n> both MSYS2 and native Win32 to have its own set of compatibility issues,\n> so that could be worth it?\n\nHmm, I don't know. It is a distinct platform with its own set of peculiar\nissues. So, it may be worth it. However, I wouldn't want to expend CI\nresources on a platform which has an unknown user-base. How many cygwin\nusers are there? (it can sometimes feel like there are very many, sometimes\nmaybe just a handful!). ;)\n\n\n> For the record: I don't really have much of an opinion on this given\n> that I tend to not use Windows, except when I (once again) break some\n> tests there. Especially the path handling si something that tends to\n> cause lots of confusion on my side.\n\nYou are not alone!\n\nATB,\nRamsay Jones\n\n\n"}]}