Re: [Flightgear-devel] Potential startup speed fix
Following up on my own message: With a very minor modification, the patch works. Considering the exceptionally bright weather we have right now, I won't be spending much time behind a computer today. Hopefully I can wrap up a new patch tonight after sunset though... Cheers, Durk On Saturday 28 May 2005 06:45, Durk Talsma wrote: I just did a quick test and it looks like the parking and rwyuse files are not yet picked up by the patch. I'm likely to have a chance to look into this tomorrow. I'm out of town for the rest of the day. Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Ralf Gerlich wrote: Erik Hofman schrieb: These issues should be fixed now. That was the second alternative I wanted to propose ;-) Just to be certain, these problems are now solved, aren't they? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Just to be certain, these problems are now solved, aren't they? Yes, they are. At least for me, can't speak for others...;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
Andy Ross wrote Vivian Meazza wrote: Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for a brew a coffee - and that's on a pretty powerful machine. Time from execution to fade in of the cockpit display is about 10 seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this down. One issue that had been discovered earlier is that an AI-related patch to the the airport loading code in February causes the startup routine to try to load a rwyuse.xml and parking.xml file in every one of 24597 potential directories under $FG_ROOT/Aiports/AI. Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) The results of this patch are very encouraging: Airports and Navigation Data Total Before 2 min 40 sec3 min 50 sec After 1 min 40 sec2 min 50 sec It's still the most significant part of the load process - can we be even more clever yet? Nothing seems to be broken ... but I haven't tested exhaustively I'll try the plib patch later. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Airports and Navigation Data Total Before2 min 40 sec3 min 50 sec After 1 min 40 sec2 min 50 sec It's still the most significant part of the load process - can we be even more clever yet? How about an un-clever solution? Can we just divide the existing data up into regions, and let the user select which regions he wants before start up? Even the 737 I fly doesn't keep a worldwide data set. For the OV10 sim I cut out all but some of the German bits, and the load time for airports/navaids went from about 10 seconds to 0 seconds. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Norman Vine wrote: On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Hmm could you please whare with us what isn't 'robust' about the Cygwin file system. It is slow compared to the Linux or Native Win32 file system in that it has to go thru an extra translation layer inorder to get Unix behaviour under Win32 but . implying that Cygwin file operayions are not robust borders on pure fud Hi Norman, I think you just need to read Andy's words as a fancy way to say slower. :-) I'm sure he's not questioning the correctness of the results. I know that you know all this, but for the sake of others, unix is optimized to efficiently run a lot of little processes or threads at the same time, all competing for the same cpu. It is also pretty well optimized for lots of little disk accesses, and has a pretty efficient file cataloging/indexing system (and linux has about 42 different journaling file systems choices each with their own strengths and weaknesses.) :-) Windows tends to do it's best when it's running one really big application or loading one really big file ... i.e. you fire up Word to edit your 100Mb power point presentation. That is often the typical use for a windows machine ... one person doing one primary thing at a time. Unix was designed from the start to handle multiple users running many little applications all at the same time and do it efficiently and cleanly so each user thinks he/she has good performance and hopefully doesn't notice anyone else is even using the same machine. Unix has been doing this stuff for 40 years now so it's really good at it. Windows started out as DOS which had no multitasking capability, had an extremely rudimentary file system, and extremely rudimentary memory management ... microsoft has tried to grow (or beat) their product into a full fledged, modern, multitasking system, but we have all seen their struggles over the years addressing issues like memory protection (so one errant app can't take down the whole system), expanding their file system limits, trying to develop some sort of sensible security model, etc. They've gone from cooperative multitasking in the early versions of windows to preemptive multitasking in the later versions. The file systems have improved, memory management has improved, security and protection has improved, pretty much everything has improved. But it as been a process where the 800 pound gorilla has beat these features into a rudimentary system (dos) where all these modern operating system concepts were never really conceived or intended, rather than having them designed in at the start. Clarity of design purpose is a luxury unix has enjoyed ... although like windows, it has changed significantly over the years to adapt to new needs and new ideas ... So if you are running a lot of little applications all at the same time, or trying to read/write a bunch of little files all at the same time, unix generally seems to beat the pants off windows. That's not necessarily a common scenario so don't take that as a knock against windows. However, we do hit this at times with FlightGear so it can bite windows users in the sense of much slower load times than the unix people are seeing. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Curtis L. Olson snip i.e. you fire up Word to edit your 100Mb power point presentation. snip Yep, that sounds like a Windows user... Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Vivian Meazza wrote: The results of this patch are very encouraging: Airports and Navigation Data Total Before2 min 40 sec3 min 50 sec After 1 min 40 sec2 min 50 sec It's still the most significant part of the load process - can we be even more clever yet? Wow... my (decidedly mid-range) system is literally 17x faster than that. Can you provide more detail? How much memory do you have on the box? (i.e. are you running out of buffer cache and hitting the hardware -- my 10 second number is with a primed cache on a 1GB system). If hardware I/O is the bottleneck, are you using FAT? If so, how long has it been since you defragged your drive? (Or for that matter: used a spyware checker recently? etc...) The apt.dat.gz file is big, certainly. It has 165976 lines, only 91813 of which are actually used by the parser*. * So in principle you can get another 2x speedup by pruning the file from the raw X-Plane version. Attached is a little perl script that does that. Untested. Use it as someting like: zcat apt.dat.gz | fgapt.pl apt.dat Whether this is worth using a modified file is questionable. Again, on my machine it would save about 2 seconds. Shrug. The problem is that this file parses acceptably fast on my box (about 4 seconds), so it isn't CPU speed that's the problem. I even wrote a quickie hand-optimized parser in C to see if the STL in the existing one was causing slowness and it's not (my parser gets through the file in about 2 seconds, but doesn't do anything with the data). And I/O from the file it is handled by zlib, which should be reading large chunks at a time; on linux, it reads chunks of 16k, which shouldn't be slow even on windows. That comes out to about 210 reads over 100 seconds as per your numbers above, and if your cygwin is really taking half a second (!) per 16k read, then something is badly wrong way beyond what FlightGear can fix. I have to believe there is something at work here beyond mere windows/cygwin slowness. I do have a windows machine handy, however, so I'll try to do a cygwin build today and see how it works. I notice that cygwin *does* have a strace equivalent. If you get a chance, try running: strace -t fgfs really-huge-log-file.txt (Apply the plib patch before doing this, as it will reduce the syscall count and make the resulting file smaller). This will slow things down even more, but should give you some idea of where FlightGear is spending its time. Search down to where you see it open apt.dat.gz and watch the reads and how long they take. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
I wrote: Attached is a little perl script that does that. Untested. Use it as someting like: Oops. Andy fgapt.pl Description: Perl program ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Andy Ross wrote: The apt.dat.gz file is big, certainly. It has 165976 lines, only 91813 of which are actually used by the parser*. * So in principle you can get another 2x speedup by pruning the file from the raw X-Plane version. Attached is a little perl script that does that. Untested. Use it as someting like: zcat apt.dat.gz | fgapt.pl apt.dat Whether this is worth using a modified file is questionable. Again, on my machine it would save about 2 seconds. Shrug. I had that on the back of my mind for some time now and decided to implement it today. Lines that are not needed for FlightGear are not tokenized anymore which should provide at least some speedup again. I've also changed the if tests from strings comparison to int comparisons to speed it up just slightly more. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: [SNIP] I had that on the back of my mind for some time now and decided to implement it today. Lines that are not needed for FlightGear are not tokenized anymore which should provide at least some speedup again. I've also changed the if tests from strings comparison to int comparisons to speed it up just slightly more. Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Obviously in.getline() includes the carriage return (checked that with --log-level=bulk), which was previously swallowed by simgear::strutils::split(). That way !token.size() could detect the empty line. Also it seems that an empty line which consists of spaces will not be detected by the new code, but as people should not edit the apt.dat-file manually anyway, that might not be as important. One could add a note to the error message Unknown line in file: though. Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Ralf Gerlich wrote: Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Odd, I don't see that, are you using Windows or MacOS? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Ralf Gerlich wrote: Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Obviously in.getline() includes the carriage return (checked that with --log-level=bulk), which was previously swallowed by simgear::strutils::split(). That way !token.size() could detect the empty line. Also it seems that an empty line which consists of spaces will not be detected by the new code, but as people should not edit the apt.dat-file manually anyway, that might not be as important. One could add a note to the error message Unknown line in file: though. These issues should be fixed now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: Ralf Gerlich wrote: Unfortunately that seems to break skipping the blank lines which are in the standard apt.dat-files. I get an Unknown line in file:-message when the reader encounters the first blank line after the version line. Odd, I don't see that, are you using Windows or MacOS? None of them...Linux...obviously Robin's apt.dat (DAFIF cycle 200505) contain '\r\n' at the end of the line (DOS-convention) and the istream::getline(char*,streamsize) implementation of the Linux libstdc++ for g++-3.4 reads all characters until the '\n' - at least according to the istream header file. Possibly the implementations on the other platforms using different conventions handle this differently, masking the error on some platforms. I've attached a patch for a simple fix, also fixing the problem with the space-only lines. Ralf apt_loader-patch.bin Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Erik Hofman schrieb: These issues should be fixed now. That was the second alternative I wanted to propose ;-) Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
I just did a quick test and it looks like the parking and rwyuse files are not yet picked up by the patch. I'm likely to have a chance to look into this tomorrow. I'm out of town for the rest of the day. Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Potential startup speed fix
Vivian Meazza wrote:
Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for
a brew a coffee - and that's on a pretty powerful machine.
Time from execution to fade in of the cockpit display is about 10
seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this
down.
One issue that had been discovered earlier is that an AI-related patch
to the the airport loading code in February causes the startup routine
to try to load a rwyuse.xml and parking.xml file in every one of 24597
potential directories under $FG_ROOT/Aiports/AI.
Attached is a patch that pre-reads the directory contents ahead of
time (currently that is a list of length zero) to avoid having to hit
the kernel (twice!) for every airport.
Under Linux, this doesn't provide much speedup. But Windows (and
especially the cygwin libraries) has a somewhat less robust I/O system
in the face of many tiny operations. Hopefully it will help there.
Can someone on each of cygwin, mingw and/or MSVC try this out and see
if it helps?
Unfortunately, because there is no actual parking/runway AI data in
the base package, much of this is currently dead code that cannot be
tested. I can't promise I didn't break anything, because I have no
way of knowing whether it worked in the first place. :)
Andy
Index: src/Airports/simple.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Airports/simple.hxx,v
retrieving revision 1.12
diff -u -r1.12 simple.hxx
--- src/Airports/simple.hxx 10 Feb 2005 09:01:51 - 1.12
+++ src/Airports/simple.hxx 26 May 2005 20:47:33 -
@@ -42,10 +42,12 @@
#include STL_STRING
#include map
+#include set
#include vector
SG_USING_STD(string);
SG_USING_STD(map);
+SG_USING_STD(set);
SG_USING_STD(vector);
typedef vectorstring stringVec;
@@ -306,11 +308,12 @@
airport_map airports_by_id;
airport_list airports_array;
+set string ai_dirs;
public:
// Constructor (new)
-FGAirportList() {}
+FGAirportList();
// Destructor
~FGAirportList();
Index: src/Airports/simple.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Airports/simple.cxx,v
retrieving revision 1.17
diff -u -r1.17 simple.cxx
--- src/Airports/simple.cxx 25 Feb 2005 19:41:53 - 1.17
+++ src/Airports/simple.cxx 26 May 2005 20:47:33 -
@@ -1149,6 +1149,26 @@
* FGAirportList
*/
+// Populates a list of subdirectories of $FG_ROOT/Airports/AI so that
+// the add() method doesn't have to try opening 2 XML files in each of
+// thousands of non-existent directories. FIXME: should probably add
+// code to free this list after parsing of apt.dat is finished;
+// non-issue at the moment, however, as there are no AI subdirectories
+// in the base package.
+FGAirportList::FGAirportList()
+{
+ulDir* d;
+ulDirEnt* dent;
+SGPath aid( globals-get_fg_root() );
+aid.append( /Airports/AI );
+if((d = ulOpenDir(aid.c_str())) == NULL)
+return;
+while((dent = ulReadDir(d)) != NULL) {
+cerr Dent: dent-d_name; // DEBUG
+ai_dirs.insert(dent-d_name);
+}
+ulCloseDir(d);
+}
// add an entry to the list
void FGAirportList::add( const string id, const double longitude,
@@ -1172,7 +1192,8 @@
rwyPrefPath.append( /Airports/AI/ );
rwyPrefPath.append(id);
rwyPrefPath.append(rwyuse.xml);
-if (parkpath.exists())
+if (ai_dirs.find(parkpath.str()) != ai_dirs.end()
+ parkpath.exists())
{
try {
readXML(parkpath.str(),a);
@@ -1181,7 +1202,8 @@
//cerr unable to read parkpath.str() endl;
}
}
-if (rwyPrefPath.exists())
+if (ai_dirs.find(rwyPrefPath.str()) != ai_dirs.end()
+ rwyPrefPath.exists())
{
try {
readXML(rwyPrefPath.str(), rwyPrefs);
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Andy Ross wrote : Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? It halves the airport and nav loading time ( 9 - 5 s ) so the total loading time goes from 23s to 19s on my Athlon64 3400+ This is compiled with MSVC 7.1 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
Andy Ross Vivian Meazza wrote: Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for a brew a coffee - and that's on a pretty powerful machine. Time from execution to fade in of the cockpit display is about 10 seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this down. One issue that had been discovered earlier is that an AI-related patch to the the airport loading code in February causes the startup routine to try to load a rwyuse.xml and parking.xml file in every one of 24597 potential directories under $FG_ROOT/Aiports/AI. Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) I'll test it in Cygwin tomorrow: I don't have time tonight. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Hi Andy, Thanks for looking into this. I had started working on a patch, but didn't have a chance to finish it. (See AI weirdness thread earlier this month). I do have a limited number parking and rwyuse files, so I'll test it tonight. As for the parking/runway files: I've started adding some ground network node editing support to Taxidraw, so once that works, people should be able to start decorating their favorite airport Real Soon Now (TM). Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Hmm could you please whare with us what isn't 'robust' about the Cygwin file system. It is slow compared to the Linux or Native Win32 file system in that it has to go thru an extra translation layer inorder to get Unix behaviour under Win32 but . implying that Cygwin file operayions are not robust borders on pure fud Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
