Mail Archives: djgpp/1998/05/04/08:13:41
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 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.
But that's much more simpler, in fact I'll use a simple routine to avoid this
problem. Is just that we don't have to convert the first \\ to drive:/ if the
first name belongs to a Novell server.
> 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).
Well I didn't make any deep test, but I can open the files like this:
fopen("\\SERVER\PATH\FILE.NAM","rb");
fopen("\\server/path/file.nam","rb");
Both under DOS and W95.
> 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.
Of course not.
> 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.
I can workaround it, but the strange name comes just from _truename.
> > 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.
We must take a look to the Novell's API, I guess is possible to know the name
belongs to an attached server.
> 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.
I'm just making: truename and then fixpath. The first to avoid problems in DOS
when the user saves a file like this: "123456789.123". truename cuts the "9"
but as a side effect converts the name in all upper case + back slashes, so I
pass it to fixpath. Of course I'll just replace fixpath by my own function, but
is a bad thing.
> > 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.
Ok.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -