Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , djgpp AT delorie DOT com Date: Mon, 4 May 1998 09:18:58 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: fixpath problem in Novell drives. References: In-reply-to: Precedence: bulk Eli Zaretskii 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