Date:	Sun, 15 Mar 1998 15:31:37 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc:	djgpp AT delorie DOT com, Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Subject:	Re: Rebuilding config.in in gcc-2.8.1
In-Reply-To:	<3507A327.28E2@rug.ac.be>
Message-ID:	<Pine.SUN.3.91.980315153110.9861E-100000@is>
MIME-Version:	1.0

On Thu, 12 Mar 1998, Vik Heyndrickx wrote:

>     /* LFN rename */
>     r.x.ax = 0x7156;
>     /* Source name: 'autoh14321' */
>     r.x.dx = __tb_offset;
>     r.x.ds = __tb_segment;
>     /* Destination name: '9$$djren$$.$$temp$$' (sic) */
>     r.x.di = __tb_offset + olen;
>     r.x.es = __tb_segment;
>     /* At this point:
>        no file with the name '9$$djren$$.$$temp$$' exists.
>        A file with the name 'autoh14321' does exist.
>        Its DOS attribute read/only is not SET.
>        (and those three things are no speculation BTW) */
>     _put_path2(tempfile, olen);
>     _put_path(old);
>     /* I know that these _put_path instructions DID work
>        as they were supposed to, meaning that at the other
>        end (the DOS side) of the INT21 call these names
>        are seen correctly. It is no bug in _rename, but
>        I start to wish it were! */
>     __dpmi_int(0x21, &r);
>     /* This call fails with error code 5 (_DOS_ERR_ACCESS)
>        while it was supposed to succeed */

Are you sure that the call which failed is to rename `autoh14321' into
`9$$djren$$.$$temp$$' and not where the latter monster is renamed into
`config.in'?  The code lines that you quote do not exactly follow the
sources I have (in the order I see them in the library sources), so I
have trouble verifying this.

- Raw text -