Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<35054A42.4ECC@rug.ac.be>
Date:	Tue, 10 Mar 1998 15:12:18 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp AT delorie DOT com
Subject:	Re: Rebuilding config.in in gcc-2.8.1
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980310152913 DOT 4739D-100000 AT is>

Eli Zaretskii wrote:
> 
> On Tue, 10 Mar 1998, Vik Heyndrickx wrote:

> NEXIST?  What's that?  Maybe EEXIST?  Or ENOENT?
ENOENT, sorry. I didn't write it down. I see too many error code symbols
lately, I started mixing them ;-)

> What happens if you replace "mv foo config.in" with something like this:
> 
>         mv -f foo config.in || cp -f foo config.in
> 
> Does this help?

I can try, but I'm trying to find the real reason why it fails, because
if it is a bug somehow, it may also fail on other occasions.

> > At that time no config.in exists and autoh????? does exist. I've not a
> > clue why this happens.
> 
> One possible reason might be that the destination file name is more than
> 8 levels deep under the root directory.  (This only happens on plain DOS.)

I tried it in Win95 lfny, and the command line invocation works.

> Another possible reason (on Windows 95 only) might be that you have an
> old port of `mv'.  Please make sure you have the latest Fileutils port
> (circa December 1997).

It is certainly the latest. After I encountered this (?)bug, it has even
become the one compiled on Mar 8, 1998, to find out what exactly fails,
because that ENOENT error was certainly not correct. I now the exact
code line in the library core that fails. And I haven't got a clue why.
I even know that the correct filenames are passed to the INT21-7156h
call.
i.e. 'autoh14625' and a temporary filename (with a lot of dollar
characters) to work around a Win95 bug (see the libc sources).
 
> > The only reason I can think of is that the
> > autoh????? file is still open by some process, and since the only
> > process still running is bash, could this be a bug in bash?
> 
> I find it hard to believe.  First, Bash has no reason holding a file
> open, since it doesn't read or write it at that point (if I understand
> the situation correctly).  

Or it must be a program different from bash, that is run from within the
script and is still running when mv is run. But this cannot be the case
in DOS, can it?

That is also what puzzles me deeply.

> And second, every time I suspected Bash to be
> responsible for some weird behavior, it turned out to be someone else's
> (guess who's) fault. (I'm talking about almost two years of experience
> running complex shell scripts.)  This doesn't prove anything, but it does
> tell something about the quality of the Bash port (thanks a lot, Daisuke
> Aoyama!).
> 
> Of course, you should make sure you have the latest port of Bash.

And also this I can confirm it to be the latest port and release.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -