Mail Archives: djgpp-workers/2001/09/28/11:38:49
> I don't think it will be dead code (see below), but even if it is, why
> should we care so much about dead code? It just sits there, doing no
> harm. Isn't my personal happiness worth a few lines of dead code? ;-)
Right now I'm discarding truename UNC results (and using getcwd) if
I see them. But if you want me to add a few lines of dead code to
keep you happy, I'll give it a try. :-)
What's currently in the code is if it sees a UNC it just decides to
return the absolute path that getcwd returned. (My reasoning: this
code can only be activated if lfn=y and ver=0x532. I've never seen a
UNC in this environment. The only reason we jumped to this code was
root dir paranoia, and the hope we can catch and fix deep dir bugs. If
I see a UNC it is not the "bug" I've observed before, I have no idea
what is going on, so instead of making things worse I revert to
old behavior, don't use the truename result at all, and don't try to
change anything).
> I'm sorry my memory is too feeble to remember what system
> configuration used to return a UNC. But I clearly remember that I
> needed at some point to do a rewrite in `stat', relying on _fixpath
> instead of _truename. `stat' now uses _truename only to detect
> character devices, resolve SUBST and JOIN, and as an argument to the
> function which invents the inode numbers; everything else, including,
> significantly, the drive letter, is taken from _fixpath.
>
> To back up my failing memory, I reproduce below the entry from RBIL
> for the _truename function. Note that it explicitly says a UNC result
> is possible. It also says that some versions of MSCDEX return a UNC
> (since CDROM drives are marked as both character devices and network
> drives). So maybe testing with a CD on a DOS system will bring you a
> UNC.
>
> As an aside, note that using _truename might return a drive letter
> which is different from what we expect, due to JOIN and SUBST. I
> don't know if this will cause any trouble--it probably won't--but I
> thought I'd mention it anyway.
Join isn't supported on W2K, but subst is. I'll need to double check
that. I'll also check CD roms. Since this code can only be executed
on W2K/XP/NT+LFN, I only need to handle things that environment
supports. By the way, this section of code will never call AH=60
truename call, it will always call the 7160 version (does it ever
return UNC?)
- Raw text -