Mail Archives: djgpp-workers/2001/09/24/05:49:56
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.
- Raw text -