delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/05/03/10:41:08

Date: Sun, 3 May 1998 17:39:27 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc: djgpp AT delorie DOT com
Subject: Re: fixpath problem in Novell drives.
In-Reply-To: <m0yUb1b-000S3rC@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.980503173906.19706K-100000@is>
MIME-Version: 1.0

On Wed, 29 Apr 1998, Salvador Eduardo Tropea (SET) wrote:

> _fixpath makes some wrong things with Novell file names.

Actually, it's a much deeper problem than that: DJGPP doesn't support
UNCs at all.  It's as simple as that.

Why?  Because there is no way we know of to quickly map a UNC such as
\\SERVER\PATH\FILE.NAM to one of the drive letters, and many DOS calls
don't support UNCs (so they *have* to be mapped).

Without an efficient way of mapping a UNC to a drive letter, it is
impossible for the library to support such names transparently.  For
example, would you agree that every filename-oriented function would
issue a network call for all of the 32 possible drives, each time it
is called?  I don't think so; it would take programs eons to run to
completion if we did that.

Windows 9X supports UNCs a lot better, but even there I'm not sure to
what extent does this support go, and in particular what happens if
you issue legacy DOS calls, like under LFN=n.  If somebody could sit
down, try using UNCs with all the different Int 21h calls in low-level
libc functions, and then report the results, we might begin thinking
about whether supporting UNCs on Windows alone would be feasible.  But
even then, it would require a non-trivial rewrite of many libc
functions which work with file names.

Until then, the best way I can suggest is to solve the problem at the
application level.  If you could explain why do you need to pass such
names through `_fixpath', I will try to suggest a solution.  The usual
generic way of solving this, if such names are not too likely to
appear, is to map them into the usual DOS d:/foo/bar name, before
doing anything else.

>   Of course that's very wrong. I need something like:
> 
> \\server/path/file.nam

I don't see how `_fixpath' could do that, since it has no idea that
\\SERVER\PATH is special and different from, say, \\windows\\command.
One of `_fixpath's goals is to collapse multiple slashes into a single
slash, so it needs some way of knowing why this case is different.

Also, many programs convert all backslashes to forward slashes, which
would yield //server/path, and only *then* pass it to `_fixpath'.  So
relying on \\ at the beginning won't work as well as it seems.

> The last works ok (I can open this file). Now my question is: is possible to 
> add it? is it worst?

I think just changing `_fixpath' to pass through the magic double `\'
at the beginning would actually make things worse, because various
other functions will begin failing for no apparent reason, at least on
DOS.

> does anybody know what service can be used to find if "SERVER" is a
> valid Novell server?

The only way known to me is by calling function 5F02h of Interrupt 21h
in a loop, up to 35 times, and each time compare the returned
network-wide name with the beginning of the candidate \\SERVER\PATH
style name.  This is painfully slow (I've seen the loop issuing 5F02h
to take a full second or so), and you cannot cache the results (since
network mappings can change out of control of your program), but it's
the only way I know of that works.  I guess if you don't have to
validate too many such names at a time, it will work.

For details of this method, see the function `get_netredir_entry' on
mntent.c in the library sources.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019