Date:	Tue, 19 Mar 1996 19:26:42 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Mat Hostetter <mat AT ardi DOT com>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gdb info
In-Reply-To:	<m0tz4KW-000GPWC@gwar.ardi.com>
Message-Id:	<Pine.SUN.3.91.960319191311.21398C-100000@is>
Mime-Version:	1.0

On Tue, 19 Mar 1996, Mat Hostetter wrote:

> This is for the nonexistent file `badfile', in C:/tmp (the working directory):
> 
>  _truename returns nonzero.  canon_path is:
> 
>  C:\tmp\BADFILE
> 
>  drv_no is correctly derived from the "C:" prefix.
> 
>  The __findfirst call on stat.c:522 returns nonzero.  The else clause on
>  line 590 is successful:
> 
>   else if (!_is_remote_drive(drv_no) && !__findfirst(path, &ff_blk, FA_LABEL))

Of course, the FA_LABEL bug rears its ugly head again!  This clause was
added when it was discovered that some network drives made trouble under
Win95 when FA_LABEL bit was set in the `findfirst' call on line 522.  The
solution was to check for labels separately, and then only for local
drives.  Now it seems that at least for NT, local drives also have this 
problem.  Hmmm...  How about the ff_name (sp?) field of ff_blk--does it 
return something which ends with ``BADFILE''?  If it returns garbage that 
can be reliably recognized as garbage, we could test for it.  A *real* 
volume label should return as "C:\\LABELNAME"; maybe anything else (like 
excess backslashes and such) can be taken as a sign of this problem and 
added to the above `else if' clause?  Comments, anyone?

Mat, can you please see if the above can solve the problem in your case?
Thanks. 

- Raw text -