On Nov 20 21:52, Takashi Yano wrote: > On Tue, 19 Nov 2024 22:18:11 +0100 > Corinna Vinschen wrote: > > On Nov 19 19:13, Takashi Yano wrote: > > > On Tue, 19 Nov 2024 10:49:39 +0100 > > > Corinna Vinschen wrote: > > > > > [PATCH v2] Cygwin: flock: Fix overlap handling in lf_setlock() and > > > > > lf_clearlock() > > > > > as well? > > > > > > > > Give me a bit of time. While the patch might fix the problem, what > > > > bugs me is the deviation from upstream code. We will at least need > > > > a few comments to explain why we don't follow the upstream behaviour. > > > > > > I've got it. Does this code come from 'upstream'? From what code? > > > > This was once ripped from FreeBSD code in 2008. The upstream code > > has changed considerably, though, so I'm not so sure if my reluctance > > makes any sense. > > > > > Essentially, the ovcase 1 can be a part of ovcase 3. I guess the > > > 'upstream' does not add lock entry having same lock range unlike > > > current cygwin (lf_ver related). So, ovcase 1 can break after > > > handling 1 overlap. However, we need find overlap repeatedly > > > because we have lf_ver. > > > > Yeah, I get that. What bugs me is that the structure of the upstream > > snippets changed, not the necessity for change. For that reason alone, > > I would prefer that the `case 1:' expression stays where it is in > > lf_clearlock. But that's unreasonable. > > > > It's a puzzle of life that one thinks in 2008, that this upstream > > code will always stay what it is. A mere 16 years later... > > > > Ok, never mind that. Please push. Maybe add a single-line comment > > why we deviate from the original 2008 FreeBSD code at these points. > > Thanks for reviewing. Pushed.
Thanks for the comments! Corinna
