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

[Nicholas Wourms]

Chris wrote:

> 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.

No, I sent it to the main list.  Of course I know better then to just 
send a bug report here.  The only reason I included some observations in 
the previous message was because I felt it to be apropos to the 
discussion.  As for my discourse on strict case checking, I didn't think 
it was appropriate for cygwin-apps, since that list is only for 
discussing packaging issues and setup.exe.  Perhaps I went too far, and 
if that is the case, I'm sorry for having done that.

> 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.

I'm not sure how to take this.  I'd say discussing the problem and 
providing observations is one way to approach a solution.  I personally 
believe that following the methods of scientific inquiry yield better 
results in the end.  However, there are times when I've been guilty of 
deviating from this line of thinking, resorting to whining instead.  I'm 
not afraid to admit that I don't have all the answers or that I 
personally can't stand working with or doing anything in C++.  I'm 
willing to identify and fix problems when I'm able to, but I shouldn't 
think it necessarily be a prerequisite to engage in a discussion of 
related problems.  If you feel this attitude disqualifies me from 
participating on this list, then I won't.

> 
>>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.

False results or, even worse, unintentional actions on targets 
misidentified because of case confusion.  With an error message, you can 
at least know what the conflict is and take appropriate steps.  I've had 
cvs screw up in the past and "accidentally" delete a file it wasn't 
supposed to.

> 
>>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.

Or it could be that I'm anal about accuracy...

> 
>>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"?

That's one way to look at it.

> 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.

I guess I misread what you were trying to say, thanks for the clarification.

> 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.

[What you are about to read does contain some radical speculation on my 
part, so feel free to flame away, my asbestos suit is ready and waiting...]

Well this may be true now, but I don't think it necessarily has to be 
(in every case).  More and more, I see Cygwin evolving into something 
bigger, growing beyond what it was originally intended to do.  The 
question is, how willing are people to diverge from the status quo of a 
monolithic dll and take Cygwin to the next level?  For example, take 
ioperm, which I see as simple, yet ingenious way of providing that 
particular functionality via a system device driver.  By bypassing all 
together the upper layers of the many layers of abstraction that make up 
the Windows  OS "Onion"[1], he made possible something which, if he were 
to only use the Cygwin dll, might not be possible or would be noticeably 
slower if it were.  I've long thought of means be which we could improve 
and extend our filesystem api, and in doing so, bring feature parity 
among the various os' with respect to every aspect of Cygwin's 
file-handling.  I've wondered about the possibilities of a 
Cygwin-specific vfs implementation which was contained within a single 
file (akin to DoubleSpace or the vfs of VirtualPC) might be.  I'm sure 
there are many arguments against it and creating it obviously would be a 
monumental task to undertake, but if it were coupled with a good caching 
system, it could be better then the underlying real fs.  And if you 
really want to get fancy, one could even write a native driver to allow 
Windows to recognize and mount the fs under a drive letter (One such 
example of this is the ext2fs driver for Win32).  I'm not really serious 
about that actually happening, it is just one example of the many 
possibilities for Cygwin, once one thinks beyond the monolithic dll 
concept.  What about the potential mess this could make, perhaps you 
might wonder?  Another of my "crazy" ideas would be to have a single 
system device driver which would act as an intermediary for modular, 
Cygwin "plugins".  Somewhat akin to kernel modules, my thoughts were to 
provide this for writing extensions for Cygwin which reside within the 
Cygwin tree.  Realistically, at my current level of experience, I don't 
think I could do any of this, assuming that it is even possible (which, 
for security reasons, it may very well not be).  Despite this, I'm 
continuing to research these subjects, in the hopes that I can do as you 
say and make a concerted effort to provide concrete solutions.

Cheers,
Nicholas

[1] Something I picked up from a book I've started to read called 
"Programming Win32 Under the API" (http://www.cmpbooks.com/product/1075).

---
"Some see things as they are and you ask why? But I dream of things that 
do not (yet) exist, and I ask why not?" --- George Bernard Shaw