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

[Nicholas Wourms]

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).  So, 
I just gave up a long time ago and resigned myself to either using 
DrMingW or running stuff directly inside gdb.  Of course, it would be a 
good thing if someone could track this down.

As for the "silent" exit, this is something I've noticed on both Win2k 
and WinME.  I don't know if this is related, but for a few months now, 
I've been experiencing "involuntary" logouts with bash.  It happens more 
often on my Win2k box when I'm logged in remotely using ssh.  I'll be 
running `rm -fr` or `grep -rin` on some directory tree, and then boom, 
it drops me back to the client machine's command prompt.  Other times, 
at random, I'll login locally in rxvt via `login` and then attempt to 
run `ls` as the first command, only to have myself logged out 
immediately.  Sometimes this event happens slow enough that I can see 
the actual word "logout" before the rxvt window disappears.  Also, the 
interesting thing is that the history, in both cases, is preserved, so I 
know bash was able to exit in a somewhat graceful manor.  I suspect, but 
cannot prove, that this general problem is exacerbated by 
case_check:strict.  I notice about a 3x increase in frequency of the 
described symptoms when that setting is in effect.  This goes, as well, 
for the other symptom I described of multiple forked sub-processes 
becoming deadlocked after a random number of forks.

I'm going to digress and address one sarcastic, rhetorical question 
about why people still use or would even want to use case_check:strict. 
  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).  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).  I could go on and on 
evangelizing on the benefits of strict case check, but I think that my 
points stated are sufficient for now.  I'll close by stating a more 
fundamental point which is that strict checking makes Cygwin behave in a 
more POSIXly Correct manner, which can be, and often is, desirable.  As 
a side thought, I think it might be interesting to see how many 
developers use this mode by default.  As for the slowness, to borrow a 
saying from Chuck, well that's like the old comedy line:  "Man: Doctor, 
Doctor! It hurts when I do this.  Doctor: Then don't do that."  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 ;-).

Cheers,
Nicholas