Date: Mon, 24 Sep 2001 12:25:14 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann cc: DJGPP developers Subject: Re: Deep dir problems In-Reply-To: <10109240611.AA16676@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Mon, 24 Sep 2001, Charles Sandmann wrote: > At this point I don't see any way to make deep directory chdir()s work on > NT+LFN, Win 2000 (normal or LFN). This means no sophisticated builds which > insist on chdir()ing deep. Better would be to fix apps to avoid chdir()ing. Fixing apps isn't practical: most, if not all, of the cases where I saw such problems come from complicated builds of large packages. These are typically built by running large shell scripts, which we don't control. > The only thing I can suggest is the following: > 1) Change chdir() to check for bad directories. Prevent setting directory > if not OK (just in case failure ignored), return error code. > 2) chdir() currently calls fixpath. If the return from fixpath is not the > root directory then getcwd() shouldn't be either. > 3) call getcwd before starting, save it. do chdir. call getcwd again. > if getcwd is root directory and fixpath result wasn't, chdir to original, > set error flag, return. Are we sure that chdir is the only function that needs to be fixed to prevent disasters in the observed cases? For example, is it certain that "rm -rf" would bail out if chdir is fixed like you suggest? What about a simple call to `remove' when the argument exceeds these limits? > This would be two extra system calls. Given the observation this can fail > with lfn=n on other Win systems I think all systems should have it. Yes, but with different conditions. I think there's no need to make any additional calls if we have LFN and the system is not NT/W2K. (What about XP, btw?) > Given that rm -rf / is about the worse thing you can do to a system, I don't > think we should fool around on this one. Let's do it for all platforms. I agree. Whatever we do, we should document this in the relevant places.