Date: Sun, 16 Feb 1997 09:51:43 +0200 (IST) From: Eli Zaretskii To: Douglas Rupp cc: djgpp-workers AT delorie DOT com, Charles Sandmann Subject: Re: fstat returns garbage In-Reply-To: <3305B8F6.3A3C5027@gnat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 15 Feb 1997, Douglas Rupp wrote: > This is on NT 4.0 w/ djgpp v2.01. > > On a recursive call to make to bootstrap gnat1, the just-built compiler > is getting bad information from fstat on it's first compilation for the > second compiler, e.g. gcc -c -B../stage1 ... > > fstat is returning a normal successful error code on a valid file > descriptor for a regular file (ada.ads), but the st_mode field contains > a value of 0x21a4 (a character special device??) and an st_size of 0 > bytes. You will have to debug this a bit more, sorry. I can understand weird things happening with st_mode, since `fstat' does some trickery to get at the attribute bits, but zero st_size? That just seems impossible, since `fstat' simply calls `filelength' (which is just a call to DOS seek functions in disguise) to get the file size, so I fail to see how that could fail. Can you step into `fstat' code, or put some debugging printf's there, and see what exactly happens in these cases? Thanks. My first gues would be that this is some bug in the DPMI host built into NT (since restarting the whole thing makes it work). As Charles would put this: ``You didn't expect quality software from a virtual monopoly, did you?'' NT's DPMI host is known to lose selectors when spawning child processes, so maybe when `fstat' needs to use _dos_ds, it somehow fails due to lack of selectors. Charles?