Date: Tue, 8 Dec 1998 13:26:24 +0000 (GMT) From: "Rich N.S. Dawe" To: djgpp-workers AT delorie DOT com Subject: Re: UNC filename support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Hello. On Tue, 8 Dec 1998, Eli Zaretskii wrote: > This was discussed before, several times. The problem with supporting > UNCs is that, unless you run on Windows 9X, where UNCs are supported by > the OS kernel, the low-level libc functions need to map the UNCs to the > usual DOS x:\foo\bar form, before they are passed to DOS functions. > Such a mapping probably needs to be done in the function _put_path. Sorry if you have discussed this before. BTW is there some kind of mirror for the mailing list archive because the DJGPP web site is really slow from here (UK) most of the time (i.e. after 10am GMT). The way I have currently implemented it, the file system extension modifies the file name directly on opening. So, you can't do things like finding the file's attributes without opening it first, etc. I suppose this partial support would be better as an add-on library (which I'm preparing anyhow) than an integral part of DJGPP. > mapping of network shares to drive letters can change while the > program runs > Thus, you cannot cache the mapping between drive letters and network > shares, you need to query the system about the mapping each time the > program references a UNC. Such a query is quite slow (may take as much > as several seconds on a large network), because AFAIK there is no DOS > function that returns the drive given a UNC, only a function which does > the opposite. From my code testing, there does seem to be a delay when first querying the functions sometimes, but after that it is very fast (on Win95 anyhow). I think Win95 caches the information. So there may not be as much overhead on each function as you imagine. You can actually enumerate the UNC shares currently mapped using NetUseEnum() (the name used in Ralph Brown's Interrupt List, INT 0x21 subfunction 0x51?? I think, maybe 0x50??). This provides you with the device name for each mapped share. > Handling all this for every file-oriented function would slow down DJGPP > programs tremendously, because _put_path is called by every libc function > which calls DOS. Could one not avoid all this overhead by emulating it at the file system extension level? Am I correct in thinking _put_path() puts the pathname into the transfer buffer? > Personally, I'm very uneasy about the lack of support for UNCs, so if it > can be done without significant slow-down, I'm for it. Definitely. The more seemless DJGPP programs are with Windows, the better. > > The only undesirable side-affect is that the filename is > > actually modified by the extension. > > You could modify a copy and keep it internally, I presume. Probably. However, after the initial open call, file functions use file descriptors, and I do not know how to find the filename given a file descriptor. If a way exists then this would be possible. An alternate way would be for the file system extension to pretend that it has emulated the call by calling the lower level open function itself. Then it would have the file descriptor. [ Currently it pretends it hasn't emulated anything - it just modifies the filename. ] ============================================================================== Rich Dawe - 4th-year MSci Physicist @ Bristol University, UK richdawe AT bigfoot DOT com, http://www.bigfoot.com/~richdawe/ ==============================================================================