Mail Archives: djgpp-workers/2001/12/27/09:50:12
On Thu, 27 Dec 2001, Tim Van Holder wrote:
> Agreed. A DOS 'cd' is impossible, as that never changes 'drives'.
> But an NT 'pushd' is possible. Since our 'chdir' is supposed to be
> Unixy, 'chdir c:/foo' should be more like pushd (i.e. 'c:; cd /foo'),
> and so UNCs should be chdir()able.
The problem is, our chdir calls a DOS function to change drives, and that
function needs a drive letter.
To do the equivalent of pushd, we need to know what system call to
invoke, and how to compute its arguments. Do you happen to know that?
> > It is also a misfeature in general to have a directory which cannot be
> > chdir'ed into. We cannot expect to get away with that.
>
> Well, I suppose we could have stat/fstat not set the 'executable' bit
> for UNC dirs; that indicates you can't chdir into them.
That won't help, I think: our chdir doesn't test that bit (and does not
call stat). The equivalent of "test -d" (IIRC, access(D_OK)) also
doesn't check that. These and other cases look at the directory
attribute bit, not at the execute bit.
In any case, even if chdir knows in advance that it cannot chdir, all you
get is perhaps a more intelligent error message. Application code will
still not expect such calamities.
> > Perhaps you could look into what Windows programs, such as COMMAND.COM
> > or CMD.EXE, do when you type "cd \\cws333\c$\djgpp".
>
> cmd.exe maps a temporary drive letter
> to the UNC 'drive' and uses that
Perhaps we could do the same. IIRC, the system call to map a drive is
something we can issue. Functions 5F03h and 5F04h of Int 21h seem like a
good beginning.
- Raw text -