This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]