Mail Archives: djgpp-workers/2001/09/27/09:50:23
> This version is fine with me, but if we do call truename, its result
> should be verified that it begins with a drive letter, not with the
> UNC-style \\SERVER\SHARE\ thingy. If we return the latter, things
> will begin falling apart, because some library functions which call
> _fixpath rely on it to return a d:/foo/bar style string. `stat' is
> one place which relies on that. I also think that Fileutils rely on
> that, but I'm not sure anymore (it was too long ago that I took a good
> look at the Fileutils sources).
> You could use the idea I sent yesterday to convert UNCs into drive
> letters, couldn't you?
fixpath is called in many heavily called routines (opendir, lstat, access,
chdir) so I want to minimize interrupts where possible. So far on
Windows 2000 and Windows 95 I have been unable to get truename to
return a \\ type name on any path sent. Could you give an example of
an OS combo which returns UNCs with truename for a relative path sent
of . (our default directory)? Maybe we just check for that OS version?
Is this a lfn platform or sfn only? Would getcwd ever fail? If getcwd
fails, and the truename returns a unc maybe we should just assert fail
or set a bogus path?
> > This version seems to behave better with lfn=n on win95 and long paths,
> > and also works with Windows 2000 on long paths and short paths. This is
> > because chdir calls fixpath which calls getcwd without checking the
> > return code, converted relative paths to incorrect absolute "root" path.
>
> getcwd has only one documented error code: 0Fh, which means ``invalid
> drive''. Returning the root directory in that case is The Right
> Thing, I think: that's what DOS stores in its CDS structure for
> invalid drives.
But this documentation is wrong from a real world sense. Even on
Windows 95 I can chdir to a directory which is just slightly longer
than 64 characters with lfn=n (the set is successful) but the getcwd
either fails or is truncated (can't remember which). The assumption
that root is the right answer in this case is the cause for transversing
the root directory. Don't assume that since chdir succeeds that getcwd
will (this is the Win2K problem with long names, and also the Win9x
problem with short names).
If the drive is invalid, I'd rather set a non-existent directory than
hazard the rm -rf / syndrome.
> Btw, it would be interesting to see what error code do we get from W2K
> for directories longer than 64 characters; perhaps that would allow us
> to be smarter about the problem.
There is no error code, it just returns empty string (which is a bug).
But I have also seen something similar on W95 in deep directories (but
not with a low level call, so I'm not sure what happened). I think we
should be very defensive about root directories since this code is
converting a relative path to an absolute path - which is bad when we
call this in opendir ...
> Also, RBIL says that you should set the carry flag before calling
> 214700h and 217147h, to make sure it is set on return if the call
> fails (evidently, some versions of DOS only _clear_ carry if
> successful, but don't _set_ it if not). Maybe we should do that as
> well, if we are touching _fixpath.
Good idea.
> Finally, IIRC, some library functions call _fixpath to support the
> /dev/c/foo and /dev/env/FOO magic. So the modified _fixpath should be
> tested against those file names, to make sure we don't break anything.
if the path sent to fixpath starts with a / the getcwd stuff is not called,
so it makes no difference.
- Raw text -