[EMAIL PROTECTED] (Eric Blake) wrote: >> Daunting, but above all, invasive and probably counterproductive, >> assuming such a bug won't remain for long. With Cygwin, such fundamental >> bugs make it seem that is will be relatively easy to tell users they need >> to upgrade to a newer version. > > The problem is that the cygwin maintainers are arguing that > the bug WILL remain for a long time - they claim that fixing it > in cygwin is too invasive and too much of a speed penalty to > the bottleneck path conversion code already in place. I disagree > with their attitude (standards exist for a reason, after all, even in > the corner cases), but have not yet been able to sway them to fix > the bug - it has been an ongoing battle for more than a year.
Well, this *is* a bit of a corner case. I can sympathize with their not wanting to fix it, if the cost would really be that high. Even if the non-conforming behavior is here to stay, I don't want to see sweeping changes (or create/maintain many wrappers) that make coreutils work around such Cygwin-specific bugs. I'm happy to leave coreutils the way it is, but if you want to avoid a test failure or two on Cygwin, I'd welcome a patch that would make `make check' skip the offending tests. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
