Date:	Tue, 19 Mar 1996 21:37:42 +0300 (MSK)
From:	"Alexander V. Lukyanov" <lav AT video DOT yars DOT free DOT net>
Message-Id:	<199603191837.VAA06399@video.yars.free.net>
To:	eliz AT is DOT elta DOT co DOT il, mat AT ardi DOT com
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gdb info

> >  _truename returns nonzero.  canon_path is:
> >
> >  C:\tmp\BADFILE

Seems that truename returns error for invalid file names (such as a.b.c,
which is invalid for FAT volume) and no error for valid but nonexistent files.
Is it a correct behavior?

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

In my case there was the real label name in ff_name except for samba
drive. I think now that samba does not support long labels and win95 fails
to check this, so the only case when ff_name contains garbage was samba
drive (The first network drive I encountered that problem on)

I think check for ff_name matching original file name will be sufficient.
It also may be reazonably to check for being label only for files residing
in root directory. (labels usually reside there, isn't it?)

- Raw text -