Re: [f]statvfs (was Re: bug in statfs)

[Christopher Faylor <cgf at redhat dot com>]

On Fri, Dec 05, 2003 at 11:52:48AM -0500, Nicholas Wourms wrote:
>Pierre Humblet wrote:
>>At 03:54 PM 12/4/2003 -0500, Christopher Faylor wrote:
>>
>>>On Thu, Dec 04, 2003 at 12:52:31PM -0600, Brian Ford wrote:
>>>
>>>>PS. I'm still seeing random silent "deaths" with the current cvs
>>>>cygwin1.dll.  Long configure scripts randomly stop in the middle.
>>>>Re-running them, they might complete, or they might stop in a different
>>>>spot.  Even configuring/compiling Cygwin again is then a hit and miss
>>>>proposition.  Does anyone else see this or have an idea how to debug it?
>>>
>>>set CYGWIN=error_start=x:\path\gdb
>>>
>>>I doubt that they are just silent exits.
>>
>>
>>FWIW, on WinME I get the pop up to the effect that there was a fault in
>>cygwin1.dll.
>>gdb doesn't kick in. 
>
>I hate to say "Me too", but it's been so long I can't remember when 
>error_start ever worked on WinME.  Same error as Pierre, GPF or 
>something similar but no GDB ever shows up.  I reported it once awhile 
>back, but there was little said (I assumed it was the "too bad, you use 
>WinME" type reaction from most people, which I've come to expect).

If you reported it here, it was more likely "This is not a bug reporting
mailing list, why aren't you fixing the problem?" reaction.  If/when I
need to use WinME, I'll probably fix it but until then, reporting the
bug in cygwin-developers is not going to get much response.

While this mailing list can be used to send complaints, bugs reports, or
heads up, we are also supposed to be fixing things here.  There is an
expectation of a certain amount of technical savvy about cygwin and a
certain amount of willingness to fix problems.

>To answer simply, gcj and (I believe) Java are unable to find
>non-jar'ed class files in the CLASSPATH with any other version of that
>setting.  Also, some projects' cvs repos are unpullable unless this is
>set (It is interesting to note that the opposite is sometimes true when
>there are dirs of same name, different case and one of them is in the
>Attic).

I can't imagine why rejecting a file with the wrong case would make
something work better, especially for CVS.

>Also, it makes bash command completion much more accurate. 
>Other times, it aides in finding the right command when binaries exist 
>in the PATH, but not the same dir, which share same name, but different 
>case (as can be seen by Harold's example).

This, at least, I understand.  It is a perfect scenario for the "Doctor
it hurts when I do that", though, as you mention below.

>Perhaps actually optimizing and/or reworking the routine would be more
>fruitful in the long term?  Of course, I'm sure patches to do this will
>be gratefully accepted ;-).

More fruitful than what?  My pointing out that this is slow?  So, in
other words, "If you make it faster then it won't be so slow and then
it won't be a problem"?

I guess I shouldn't have said that I was amazed in cygwin-apps.  If you
know what you are doing and are willing to take the performance hit,
there is no reason why you shouldn't use the options.  Turning them on
without a real need them and/or understanding the costs in using them is
not recommended.  This is why I periodically speak up about this.

Adding extra checking to the filename manipulation path has got to be
slower, especially when it involves a guaranteed disk lookup.  You could
add caching, of course, but that is not foolproof and still has
overhead.

This is the same reason why a cygwin application will never be faster
than a native windows application.

cgf