{"thread":{"id":"64442","subject":"v2.52.0-rc0 test failure on cygwin","startedAt":"2025-11-04T23:52:57Z","lastAt":"2025-11-07T06:04:54Z","messageCount":6,"participants":["Ramsay Jones","Patrick Steinhardt","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"530227","messageId":"f22c95ad-43c8-41de-8315-e707224e830b@ramsayjones.plus.com","threadId":"64442","inReplyTo":null,"subject":"v2.52.0-rc0 test failure on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-11-04T23:49:46Z","receivedAt":"2025-11-04T23:52:57Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Hi Junio,\n\nJust a quick heads up: the rc0 build on cygwin has a flaky test, thus:\n  \n  $ tail test-out-2-52-rc0 \n  Test Summary Report\n  -------------------\n  t0610-reftable-basics.sh                         (Wstat: 256 (exited 1) Tests: 90 Failed: 1)\n    Failed test:  29\n    Non-zero exit status: 1\n  Files=1024, Tests=32232, 2703 wallclock secs (23.38 usr 60.53 sys + 7886.88 cusr 10419.88 csys = 18390.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:3327: test] Error 2\n  $ \n \nInitially, while investigating the failure, I was running the test by hand and it\ndidn't fail ... So, I tried a stess test, like so: \n  \n  $ cd t\n  $ ./t0610-reftable-basics.sh --run=29 --stress-limit=10\n  FAIL  3.1\n  OK    7.1\n  OK   19.1\n  OK   18.1\n  OK    2.1\n  OK    6.1\n  OK    9.1\n  OK    0.1\n  OK   21.1\n  OK    8.1\n  OK    4.1\n  OK   10.1\n  OK   12.1\n  OK   26.1\n  OK   29.1\n  OK   17.1\n  OK    1.1\n  OK   23.1\n  OK    5.1\n  OK   11.1\n  OK   27.1\n  OK   16.1\n  OK   14.1\n  OK   30.1\n  OK   15.1\n  OK   25.1\n  OK   31.1\n  OK   22.1\n  OK   24.1\n  OK   20.1\n  OK   28.1\n  OK   13.1\n  Log(s) of failed test run(s):\n  Contents of '/home/ramsay/git/t/test-results/t0610-reftable-basics.stress-3.out':\n  Initialized empty Git repository in /home/ramsay/git/t/trash directory.t0610-reftable-basics.stress-3/.git/\n  ok 1 # skip pack-refs does not crash with -h (--run)\n  \n  ok 2 # skip init: creates basic reftable structures (--run)\n  \n  ...\n \n  ok 27 # skip clone: can clone reffiles into reftable repository (--run)\n  \n  ok 28 # skip clone: can clone reftable into reffiles repository (--run)\n  \n  expecting success of 0610.29 'ref transaction: corrupted tables cause failure': \n  \ttest_when_finished \"rm -rf repo\" &&\n  \tgit init repo &&\n  \t(\n  \t\tcd repo &&\n  \t\ttest_commit file1 &&\n  \t\tfor f in .git/reftable/*.ref\n  \t\tdo\n  \t\t\t: >\"$f\" || return 1\n  \t\tdone &&\n  \t\ttest_must_fail git update-ref refs/heads/main HEAD\n  \t)\n  \n  ++ test_when_finished 'rm -rf repo'\n  ++ test 0 = 0\n  ++ test_cleanup='{ rm -rf repo\n  \t\t} && (exit \"$eval_ret\"); eval_ret=$?; :'\n  ++ git init repo\n  Initialized empty Git repository in /home/ramsay/git/t/trash directory.t0610-reftable-basics.stress-3/repo/.git/\n  ++ cd repo\n  ++ test_commit file1\n  ++ local notick=\n  ++ local echo=echo\n  ++ local append=\n  ++ local author=\n  ++ local signoff=\n  ++ local indir=\n  ++ local tag=light\n  ++ test 1 '!=' 0\n  ++ case \"$1\" in\n  ++ break\n  ++ indir=\n  ++ local file=file1.t\n  ++ test -n ''\n  ++ echo file1\n  ++ git add -- file1.t\n  ++ test -z ''\n  ++ test_tick\n  ++ test -z ''\n  ++ test_tick=1112911993\n  ++ GIT_COMMITTER_DATE='1112911993 -0700'\n  ++ GIT_AUTHOR_DATE='1112911993 -0700'\n  ++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n  ++ git commit -m file1\n  [main (root-commit) 69af168] file1\n   Author: A U Thor <author@example.com>\n   1 file changed, 1 insertion(+)\n   create mode 100644 file1.t\n  ++ case \"$tag\" in\n  ++ git tag file1\n  ++ for f in .git/reftable/*.ref\n  ++ :\n  ./test-lib.sh: line 1017: .git/reftable/0x000000000001-0x000000000002-3b7f1804.ref: Permission denied\n  error: last command exited with $?=1\n  not ok 29 - ref transaction: corrupted tables cause failure\n  #\t\n  #\t\ttest_when_finished \"rm -rf repo\" &&\n  #\t\tgit init repo &&\n  #\t\t(\n  #\t\t\tcd repo &&\n  #\t\t\ttest_commit file1 &&\n  #\t\t\tfor f in .git/reftable/*.ref\n  #\t\t\tdo\n  #\t\t\t\t: >\"$f\" || return 1\n  #\t\t\tdone &&\n  #\t\t\ttest_must_fail git update-ref refs/heads/main HEAD\n  #\t\t)\n  #\t\n  1..29\n  $ \n\nNote the 'Permission denied' error when attempting to corrupt (empty)\nthe '*.ref' tables. (Also, this shows 1 error in 32 parallel attempts).\n\nHowever, the 'trash' directory shows that the file permissions are set\nsuch that I should be able to corrupt them:\n  \n  $ cd trash\\ directory.t0610-reftable-basics.stress-failed/\n  $ cd repo\n  $ ls -l .git/reftable\n  total 3.0K\n  -rw-r--r-- 1 ramsay None 296 Nov  4 17:56 0x000000000001-0x000000000002-3b7f1804.ref\n  -rw-r--r-- 1 ramsay None 139 Nov  4 17:56 0x000000000003-0x000000000003-66444a41.ref\n  -rw-r--r-- 1 ramsay None  86 Nov  4 17:56 tables.list\n  $ \n\nIndeed, I can do just that:\n  \n  $ : >.git/reftable/0x000000000001-0x000000000002-3b7f1804.ref \n  $ ls -l .git/reftable\n  total 2.0K\n  -rw-r--r-- 1 ramsay None   0 Nov  4 18:54 0x000000000001-0x000000000002-3b7f1804.ref\n  -rw-r--r-- 1 ramsay None 139 Nov  4 17:56 0x000000000003-0x000000000003-66444a41.ref\n  -rw-r--r-- 1 ramsay None  86 Nov  4 17:56 tables.list\n  $ git update-ref refs/heads/main HEAD\n  fatal: HEAD: not a valid SHA1\n  $ \n \nSo, this appears to be a timing issue (a bit difficult to think how it\nactually could be, but ...), so maybe try:\n \n  $ cd ../..\n  $ vim t0610-reftable-basics.sh\n  $ git diff\n  diff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\n  index 3ea5d51532..4fc5cbca99 100755\n  --- a/t/t0610-reftable-basics.sh\n  +++ b/t/t0610-reftable-basics.sh\n  @@ -205,6 +205,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n          (\n                  cd repo &&\n                  test_commit file1 &&\n  +               sleep 1 &&\n                  for f in .git/reftable/*.ref\n                  do\n                          : >\"$f\" || return 1\n  $ ./t0610-reftable-basics.sh --run=29 --stress-limit=10\n  OK    0.1\n  OK   13.1\n  OK    4.1\n  OK    1.1\n  OK    2.1\n  OK    3.1\n  OK   10.1\n  OK    8.1\n  OK   26.1\n  OK   21.1\n  OK    7.1\n  OK   19.1\n  OK    9.1\n  OK    5.1\n  OK   14.1\n  OK   22.1\n  OK   11.1\n  OK   27.1\n  OK   17.1\n  OK   29.1\n  OK    6.1\n  OK   30.1\n  OK   15.1\n  OK   23.1\n  OK   12.1\n  OK   24.1\n  OK   25.1\n  OK   16.1\n  OK   18.1\n  OK   28.1\n  OK   31.1\n  OK   20.1\n  OK    0.2\n  OK   13.2\n  OK    4.2\n  OK   10.2\n  OK    2.2\n  OK    3.2\n  OK    1.2\n  OK   22.2\n  OK    8.2\n  OK   21.2\n  OK   19.2\n  OK    5.2\n  OK    9.2\n  OK    7.2\n  OK   26.2\n  OK   11.2\n  OK   14.2\n  OK   25.2\n  OK   28.2\n  OK   15.2\n  OK   17.2\n  OK   27.2\n  OK    6.2\n  OK   18.2\n  OK   30.2\n  OK   31.2\n  OK   29.2\n  OK   20.2\n  OK   16.2\n  OK   12.2\n  OK   23.2\n  OK   24.2\n  OK   13.3\n  OK    4.3\n  OK    0.3\n  OK    3.3\n  OK   10.3\n  OK    2.3\n  OK    1.3\n  OK    8.3\n  OK   22.3\n  OK   19.3\n  OK    5.3\n  OK   14.3\n  OK   26.3\n  OK    7.3\n  OK   25.3\n  OK   15.3\n  OK   28.3\n  OK   21.3\n  OK    9.3\n  OK   11.3\n  OK   12.3\n  OK   23.3\n  OK   16.3\n  OK   17.3\n  OK   18.3\n  OK   29.3\n  OK    6.3\n  OK   30.3\n  OK   27.3\n  OK   24.3\n  OK   31.3\n  OK   20.3\n  $ \n \n[I hit ctrl-c here]\n\nSo, not really an answer, but I have noted several times over the years\nthat cygwin seems to delay setting some file attributes until after the\nprocess has exited ... [yeah, I don't see how either! ;) ].\n\nI noted the above last night and, unfortunately, I haven't had any\ntime to look into this tonight. (hopefully tomorrow).\n\n[I haven't tried bisecting because, well ... flaky test! ;) ]\n\nATB,\nRamsay Jones\n\n"},{"id":"530306","messageId":"aQx-RnNX28BPU2cS@pks.im","threadId":"64442","inReplyTo":"f22c95ad-43c8-41de-8315-e707224e830b@ramsayjones.plus.com","subject":"Re: v2.52.0-rc0 test failure on cygwin","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-11-06T10:53:58Z","receivedAt":"2025-11-06T10:54:11Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Nov 04, 2025 at 11:49:46PM +0000, Ramsay Jones wrote:\n> Just a quick heads up: the rc0 build on cygwin has a flaky test, thus:\n>   \n>   $ tail test-out-2-52-rc0 \n>   Test Summary Report\n>   -------------------\n>   t0610-reftable-basics.sh                         (Wstat: 256 (exited 1) Tests: 90 Failed: 1)\n>     Failed test:  29\n>     Non-zero exit status: 1\n>   Files=1024, Tests=32232, 2703 wallclock secs (23.38 usr 60.53 sys + 7886.88 cusr 10419.88 csys = 18390.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:3327: test] Error 2\n>   $ \n>  \n> Initially, while investigating the failure, I was running the test by hand and it\n> didn't fail ... So, I tried a stess test, like so: \n\nInteresting. My first hunch is that the root cause is auto-maintenance.\ngit-maintenance(1) spawns `git pack-refs --auto`, and that process will\nopen the stack so that it can verify whether it needs to be packed or\nnot. And Windows being Windows, the file being open may mean that it\ncannot be written by another process at the same point in time.\n\nIn any case, I was able to reproduce the issue. But disabling auto\nmaintenance with the following patch does not fix the flake.\n\ndiff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\nindex 3ea5d51532..52bbf4fe57 100755\n--- a/t/t0610-reftable-basics.sh\n+++ b/t/t0610-reftable-basics.sh\n@@ -204,6 +204,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n \tgit init repo &&\n \t(\n \t\tcd repo &&\n+\t\tgit config set maintenance.auto false &&\n \t\ttest_commit file1 &&\n \t\tfor f in .git/reftable/*.ref\n \t\tdo\n\nAnd I guess that makes sense? I'd assume that Cygwin already knows to\nopen files with POSIX semantics, so it should be possible to write to\nthe file even if it was held open by another Git process.\n\n[snip]\n> So, not really an answer, but I have noted several times over the years\n> that cygwin seems to delay setting some file attributes until after the\n> process has exited ... [yeah, I don't see how either! ;) ].\n\nWhat? That's horrible if true. How doesn't this cause more issues?\n\nI wonder whether the issue is surfaced because we use the shell to\ntruncate the file. If you instead use `file-tool truncate 0` for example\nthen I cannot reproduce the flake anymore:\n\ndiff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\nindex 3ea5d51532..1058f83993 100755\n--- a/t/t0610-reftable-basics.sh\n+++ b/t/t0610-reftable-basics.sh\n@@ -207,7 +207,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n \t\ttest_commit file1 &&\n \t\tfor f in .git/reftable/*.ref\n \t\tdo\n-\t\t\t: >\"$f\" || return 1\n+\t\t\ttest-tool truncate \"$f\" 0 || return 1\n \t\tdone &&\n \t\ttest_must_fail git update-ref refs/heads/main HEAD\n \t)\n\nBut this may very well just be due to timing again -- spawning the\nprocess will be slower than using shell redirection to trim the file.\n\nAll of this is quite curious. I don't really have any better idea than\nto use something like the above patch. It's ugly, doubly so because I\ndon't understand either the root cause nor why the patch properly fixes\nit. So I'd be grateful if anyone were to enlighten me :)\n\n> I noted the above last night and, unfortunately, I haven't had any\n> time to look into this tonight. (hopefully tomorrow).\n> \n> [I haven't tried bisecting because, well ... flaky test! ;) ]\n\nI have verified that the flake already exists in Git 2.51, so at least\nit's not a regression in the current release cycle.\n\nThanks!\n\nPatrick\n"},{"id":"530333","messageId":"bdba6156-e286-492f-a64d-52bdcf074ea1@kdbg.org","threadId":"64442","inReplyTo":"aQx-RnNX28BPU2cS@pks.im","subject":"Re: v2.52.0-rc0 test failure on cygwin","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-11-06T18:27:57Z","receivedAt":"2025-11-06T18:28:01Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 06.11.25 um 11:53 schrieb Patrick Steinhardt:\n> On Tue, Nov 04, 2025 at 11:49:46PM +0000, Ramsay Jones wrote:\n>> So, not really an answer, but I have noted several times over the years\n>> that cygwin seems to delay setting some file attributes until after the\n>> process has exited ... [yeah, I don't see how either! ;) ].\n> \n> What? That's horrible if true. How doesn't this cause more issues?\n\nUnlike POSIX write(), Windows's WriteFile() doesn't update the\nmodification time stamp immediately. It's only updated when the last\nfile handle is closed.\n\nhttps://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile\n\n> When writing to a file, the last write time is not fully updated until\n> all handles used for writing have been closed.\n\n-- Hannes\n\n"},{"id":"530340","messageId":"a8a03a31-8e06-4b72-b847-b59548156e60@ramsayjones.plus.com","threadId":"64442","inReplyTo":"aQx-RnNX28BPU2cS@pks.im","subject":"Re: v2.52.0-rc0 test failure on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-11-06T20:28:35Z","receivedAt":"2025-11-06T20:31:45Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 06/11/2025 10:53 am, Patrick Steinhardt wrote:\n> On Tue, Nov 04, 2025 at 11:49:46PM +0000, Ramsay Jones wrote:\n>> Just a quick heads up: the rc0 build on cygwin has a flaky test, thus:\n>>   \n>>   $ tail test-out-2-52-rc0 \n>>   Test Summary Report\n>>   -------------------\n>>   t0610-reftable-basics.sh                         (Wstat: 256 (exited 1) Tests: 90 Failed: 1)\n>>     Failed test:  29\n>>     Non-zero exit status: 1\n>>   Files=1024, Tests=32232, 2703 wallclock secs (23.38 usr 60.53 sys + 7886.88 cusr 10419.88 csys = 18390.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:3327: test] Error 2\n>>   $ \n>>  \n>> Initially, while investigating the failure, I was running the test by hand and it\n>> didn't fail ... So, I tried a stess test, like so: \n> \n> Interesting. My first hunch is that the root cause is auto-maintenance.\n> git-maintenance(1) spawns `git pack-refs --auto`, and that process will\n> open the stack so that it can verify whether it needs to be packed or\n> not. And Windows being Windows, the file being open may mean that it\n> cannot be written by another process at the same point in time.\n> \n> In any case, I was able to reproduce the issue. But disabling auto\n> maintenance with the following patch does not fix the flake.\n> \n> diff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\n> index 3ea5d51532..52bbf4fe57 100755\n> --- a/t/t0610-reftable-basics.sh\n> +++ b/t/t0610-reftable-basics.sh\n> @@ -204,6 +204,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n>  \tgit init repo &&\n>  \t(\n>  \t\tcd repo &&\n> +\t\tgit config set maintenance.auto false &&\n>  \t\ttest_commit file1 &&\n>  \t\tfor f in .git/reftable/*.ref\n>  \t\tdo\n> \n\nThanks for looking into this - yesterday was unexpectedly busy, so I didn't\nhave time to look at this myself. :(\n\nI also thought, briefly, about 'git maintenance' since the error seems\nto happen in parallel heavy workloads. You probably didn't notice that\nthe test finished in 45min, because I ran the test with '-j8'. I have\nrecently replaced my win10 laptop. On my old laptop, the non-parallel\ntest run used to take 6+ hours. With my new laptop it is 4+ hours, so\nit is still a long time to wait. However, the 'meson test', which by\ndefault runs the tests in parallel, was much faster (about 80-90min).\nSo, it was worth a try... At the moment the parallel tests hang about\nhalf of the time (prove hangs right at the very end!), so I am still\nexperimenting.\n\n[snip]\n\n> I wonder whether the issue is surfaced because we use the shell to\n> truncate the file. If you instead use `file-tool truncate 0` for example\n> then I cannot reproduce the flake anymore:\n> \n> diff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\n> index 3ea5d51532..1058f83993 100755\n> --- a/t/t0610-reftable-basics.sh\n> +++ b/t/t0610-reftable-basics.sh\n> @@ -207,7 +207,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n>  \t\ttest_commit file1 &&\n>  \t\tfor f in .git/reftable/*.ref\n>  \t\tdo\n> -\t\t\t: >\"$f\" || return 1\n> +\t\t\ttest-tool truncate \"$f\" 0 || return 1\n>  \t\tdone &&\n>  \t\ttest_must_fail git update-ref refs/heads/main HEAD\n>  \t)\n> \n> But this may very well just be due to timing again -- spawning the\n> process will be slower than using shell redirection to trim the file.\n\nI tried this patch tonight, letting:\n\n    $ ./t0610-reftable-basics.sh --run=29 --stress-limit=10\n\nfinish, which it did without failure. So that's 32 * 10 successful runs.\n\n(I had expected 16 * 10 yesterday, ie 2 * cores * 10, but this laptop\nhas 8 cores 16 threads, so 'getconf _NPROCESSORS_ONLN' returns 16 not 8).\n\n> \n> All of this is quite curious. I don't really have any better idea than\n> to use something like the above patch. It's ugly, doubly so because I\n> don't understand either the root cause nor why the patch properly fixes\n> it. So I'd be grateful if anyone were to enlighten me :)\n\nMe too! :)\n\n> I have verified that the flake already exists in Git 2.51, so at least\n> it's not a regression in the current release cycle.\nOK, that's good to know.\n\nDespite the mystery, I think a patch based on the above would be\nthe best solution for now. (Assuming nobody has a better idea).\n\nThanks.\n\nATB,\nRamsay Jones\n\n"},{"id":"530341","messageId":"5450446b-c1b9-4701-ae21-26da6ae35f52@ramsayjones.plus.com","threadId":"64442","inReplyTo":"bdba6156-e286-492f-a64d-52bdcf074ea1@kdbg.org","subject":"Re: v2.52.0-rc0 test failure on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2025-11-06T21:00:34Z","receivedAt":"2025-11-06T21:00:38Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 06/11/2025 6:27 pm, Johannes Sixt wrote:\n> Am 06.11.25 um 11:53 schrieb Patrick Steinhardt:\n>> On Tue, Nov 04, 2025 at 11:49:46PM +0000, Ramsay Jones wrote:\n>>> So, not really an answer, but I have noted several times over the years\n>>> that cygwin seems to delay setting some file attributes until after the\n>>> process has exited ... [yeah, I don't see how either! ;) ].\n>>\n>> What? That's horrible if true. How doesn't this cause more issues?\n> \n> Unlike POSIX write(), Windows's WriteFile() doesn't update the\n> modification time stamp immediately. It's only updated when the last\n> file handle is closed.\n> \n> https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile\n> \n>> When writing to a file, the last write time is not fully updated until\n>> all handles used for writing have been closed.\n>\nYep, I deliberately said 'seems to ...' because I have very little\nby way of hard facts! ;)\n\nWell, except, in approx 1996 on windows NT3.51 (on the only occasion\nthat I did any commercial windows programming), I had a 'problem' with\nwhat appeared to be a 'late' update to a file attribute (I can't\nremember which one - it could have been time related, rather than\npermissions). A 'windows expert' (which I have never been) gave me\na workaround for the 'windows filesystem bug' (his words).\n\nIt was at this time that I first used cygwin (beta 14 I think - I still\nhave the cygnus solutions CD somewhere). I had managed to not use\nwindows of any description before then, so I was absolutely horrified\nby the awful development environment that greeted me! (even with the\nvisual C++ GUI). So, on every laptop since then, I have immediately\ninstalled cygwin, along with dual-booting linux.\n\nIn a small way, I have tried to 'pay back' the cygwin developers, who\nsaved me from going crazy during that project! ;)\n\nATB,\nRamsay Jones\n\n\n\n"},{"id":"530354","messageId":"aQ2L_a3q7MAUJI-L@pks.im","threadId":"64442","inReplyTo":"a8a03a31-8e06-4b72-b847-b59548156e60@ramsayjones.plus.com","subject":"Re: v2.52.0-rc0 test failure on cygwin","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-11-07T06:04:45Z","receivedAt":"2025-11-07T06:04:54Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Nov 06, 2025 at 08:28:35PM +0000, Ramsay Jones wrote:\n> On 06/11/2025 10:53 am, Patrick Steinhardt wrote:\n> > I wonder whether the issue is surfaced because we use the shell to\n> > truncate the file. If you instead use `file-tool truncate 0` for example\n> > then I cannot reproduce the flake anymore:\n> > \n> > diff --git a/t/t0610-reftable-basics.sh b/t/t0610-reftable-basics.sh\n> > index 3ea5d51532..1058f83993 100755\n> > --- a/t/t0610-reftable-basics.sh\n> > +++ b/t/t0610-reftable-basics.sh\n> > @@ -207,7 +207,7 @@ test_expect_success 'ref transaction: corrupted tables cause failure' '\n> >  \t\ttest_commit file1 &&\n> >  \t\tfor f in .git/reftable/*.ref\n> >  \t\tdo\n> > -\t\t\t: >\"$f\" || return 1\n> > +\t\t\ttest-tool truncate \"$f\" 0 || return 1\n> >  \t\tdone &&\n> >  \t\ttest_must_fail git update-ref refs/heads/main HEAD\n> >  \t)\n> > \n> > But this may very well just be due to timing again -- spawning the\n> > process will be slower than using shell redirection to trim the file.\n> \n> I tried this patch tonight, letting:\n> \n>     $ ./t0610-reftable-basics.sh --run=29 --stress-limit=10\n> \n> finish, which it did without failure. So that's 32 * 10 successful runs.\n> \n> (I had expected 16 * 10 yesterday, ie 2 * cores * 10, but this laptop\n> has 8 cores 16 threads, so 'getconf _NPROCESSORS_ONLN' returns 16 not 8).\n\nNice :)\n\n> > All of this is quite curious. I don't really have any better idea than\n> > to use something like the above patch. It's ugly, doubly so because I\n> > don't understand either the root cause nor why the patch properly fixes\n> > it. So I'd be grateful if anyone were to enlighten me :)\n> \n> Me too! :)\n> \n> > I have verified that the flake already exists in Git 2.51, so at least\n> > it's not a regression in the current release cycle.\n> OK, that's good to know.\n> \n> Despite the mystery, I think a patch based on the above would be\n> the best solution for now. (Assuming nobody has a better idea).\n\nPlease feel free to take it and turn it into a proper patch. My main\ngoal was to verify that this is not a regression and that nothing new\nbroke in the reftable backend. I'm happy to let you take over from here,\nas I'm a bit short on time otherwise.\n\nThanks!\n\nPatrick\n"}]}