X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f From: "Tim Van Holder" To: "'Eli Zaretskii'" Cc: , "'Charles Sandmann'" Subject: Re: lfn from scratch... Date: Thu, 27 Dec 2001 16:53:55 +0100 Message-ID: <000101c18eee$b36ed3b0$1c7d76d5@zastaixp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > 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? Nope. Not even sure there is a DOS call for that. And we can't access the Win32 API. It might be useful to have some device driver for WinNT/2K/XP that does provide support for accessing (parts of) the Win32 API from a DOS box. That would probably make several problems a lot less complicated. Not sure how feasible that is though. > > 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). Should be easy enough to add an access(X_OK) to chdir, and modify access() and stat() not to set that attribute for UNCs. > 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. That test is irrelevant; it's the execute bit, not the directory bit that matters. > In any case, even if chdir knows in advance that it cannot > chdir, all you get is perhaps a more intelligent error message. Yes: cd \\foo\bar -> //foo/bar: Permission denied. > Application code will still not expect such calamities. Then that application code is broken; we generally deal with Unix ports, and such permission settings are fairly common on Unices. Just because user code never checks the return code of a function, does that mean we should never return failure? > > 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. The trick there would be to know when to release the mapping. For cmd.exe that's easy: as soon as you 'popd' away from the UNC. For us, that won't be easy to determine. Keeping it mapped until program end is undesirable too, especially since there are only 25 mappings available at best.